←back to thread

656 points EthanHeilman | 1 comments | | HN request time: 0.335s | source
Show context
staticassertion ◴[] No.30102061[source]
This is pretty incredible. These aren't just good practices, they're the fairly bleeding edge best practices.

1. No more SMS and TOTP. FIDO2 tokens only.

2. No more unencrypted network traffic - including DNS, which is such a recent development and they're mandating it. Incredible.

3. Context aware authorization. So not just "can this user access this?" but attestation about device state! That's extremely cutting edge - almost no one does that today.

My hope is that this makes things more accessible. We do all of this today at my company, except where we can't - for example, a lot of our vendors don't offer FIDO2 2FA or webauthn, so we're stuck with TOTP.

replies(15): >>30103088 #>>30103131 #>>30103846 #>>30104022 #>>30104121 #>>30104716 #>>30104840 #>>30105344 #>>30106941 #>>30107798 #>>30108481 #>>30108567 #>>30108916 #>>30111757 #>>30112413 #
c0l0 ◴[] No.30104121[source]
I think 3. is very harmful for actual, real-world use of Free Software. If only specific builds of software that are on a vendor-sanctioned allowlist, governed by the signature of a "trusted" party to grant them entry to said list, can meaningfully access networked services, all those who compile their own artifacts (even from completely identical source code) will be excluded from accessing that remote side/service.

Banks and media corporations are doing it today by requiring a vendor-sanctioned Android build/firmware image, attested and allowlisted by Google's SafetyNet (https://developers.google.com/android/reference/com/google/a...), and it will only get worse from here.

Remote attestation really is killing practical software freedom.

replies(16): >>30104148 #>>30104166 #>>30104241 #>>30104603 #>>30105136 #>>30106352 #>>30106792 #>>30107048 #>>30107250 #>>30107515 #>>30108070 #>>30108409 #>>30108716 #>>30108754 #>>30109550 #>>30123243 #
reilly3000 ◴[] No.30107250[source]
How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client.

If you want to get a package that is in the Arch core/ repo, doesnt that require a form of attestation?

I just don’t see a slippery slope towards dropping support for unofficial clients, we’re already at the bottom where they are generally and actively rejected for various reasons.

Still, the Android case is admittedly disturbing, it feels a lot more personal to be forced to use certain OS builds; that goes beyond the scope of how I would define a client.

replies(2): >>30108324 #>>30111229 #
1. worthless-trash ◴[] No.30111229[source]
> How could a build be verified to be the same code without some kind of signature? You cant just validate a SHA, that could be faked from a client.

This depends on how far down the rabbit hole you want to go, if it was secureboot, only signed processes can run, would that make you feel better ? If it doesn't.. what would ?