PS: The "SHA256 CHECKSUMS VERIFIED." is static. No hash check is performed, and as far as I can see the website doesn't have a list of hashes to check.
PS: The "SHA256 CHECKSUMS VERIFIED." is static. No hash check is performed, and as far as I can see the website doesn't have a list of hashes to check.
Your radar was okay: site is machine-generated by build workflow which pushes the binaries. The "Verified" label reflects internal CI attestation, but without public hashes? Might cause concern. Did not consider, tho based on your comment I've now replaced with "Digitally Signed and Notarized".
So reflects more accurately how the binaries are always digitally signed and notarized (Apple Developer ID + Microsoft Authenticode) with our company certs. SOP for my releases. The verification is the cryptographic signature checked by your OS kernel, not just a text file.
I actually like this presentation better now!
----
Public WhoIS registrant:
Chris [redacted]
The Dosyago Corporation
Beaverton, Oregon
----
OP has ~2 year old /hn/ account, with ~11k karma
----
I have made no further investigations, but obviously haven't installed this myself (as I have an IRL pager that solves similar issues to OP's).
> The system is intentionally raw. No headers, no JSON, no XML.
> Transport: UDP Port 7777
> Encoding: UTF-8 Plain Text
> Format: [SECRET::]MESSAGE
you dont get it, the protocol is flawless
> Only messages matching your Secret Key will ring.
I assume that's the "Secret Key" is placed in this prefix tag, '[SECRET::]' ?
Since plain-text over UDP is not very secret, I'm now motivated to look into how Wireguard is able to use PKI to only accept packets from a trusted clients. And, how that protocol could be used to generate the Secrey Key.