zlacker

[return to "F-Droid Fake Signer PoC"]
1. mschwa+VV[view] [source] 2025-01-04 10:34:59
>>pabs3+(OP)
I really wish we would take defining what it means for an artifact to be signed more seriously.

Which key(s) is it signed with? What is the hash of the corresponding unsigned artifact?

Signature verification tools should have some option which prints these things in a machine-readable format.

I did some work on reproducibility of Android apps and system images with Nix, and while defining a build step which can automatically establish these relationships sounds a bit goofy, it can make the issues with underspecified edge cases visible by defining verification more strictly. I did not do this to look for those edge cases though.

I am still working on that type of stuff now, but on more fundamental issues of trust we could start addressing with systems like Nix.

◧◩
2. 1oooqo+a11[view] [source] 2025-01-04 12:02:07
>>mschwa+VV
blame browsers and the url padlock "cuz users are dumb" attitude.

i still believe "pgp is too complex" was the most successful cia counter action after they lost the crypto wars to the people.

solving via nix only works within the flawed assumptions that end users either fully trust google or fdroid and are incapable of anything else.

◧◩◪
3. rollca+Ob1[view] [source] 2025-01-04 14:35:00
>>1oooqo+a11
> "pgp is too complex"

PGP is too complex. I've known my way around the command line before I learned how to hand-write, and I have to look up the commands to fetch the keys and/or verify the blob every single time. Keyservers regularly fail to respond. There's no desktop integration to speak of. The entire UX stinks of XKCD 196.

Don't blame CIA for obvious deficiencies in usability.

◧◩◪◨
4. Y_Y+5j1[view] [source] 2025-01-04 15:37:53
>>rollca+Ob1
I was with you right up until the end. I think the only thing that would stop me from sabotaging a small project like PGP (was in the early days) is moral aversion. FOSS and academic circles where these things originate is generally friendly and open, and there is plenty of money and length of rubber hose for anyone who doesn't welcome the mole into their project.

I'm not saying I have evidence that this happened to PGP specifically, just that it doesn't seem at all implausible. If the CIA told me my code was never to get too easy to use, but otherwise I could live a long and happy life and maybe a couple of government contracts it would be hard to argue.

Why a mass-market interface never took off (GPG and other descendants notwithstanding) may indicate that the whole cryptographic idea is inherently not amenable to user-friendliness, but I don't find that hypothesis as compelling.

(It could also be an unlikely coincidence that there's a good solution not found for lack of looking, but that's even less plausible to me.)

◧◩◪◨⬒
5. rollca+1m1[view] [source] 2025-01-04 16:04:21
>>Y_Y+5j1
Then why no such efforts are being pursued for PGP(GPG) nowadays?

signify[1] is approachable at least for the power users - I could print out that man page on a T-shirt. HTTPS is ubiquitous and easy, thanks to ACME & Let's Encrypt. E2EE with optional identity verification is offered in mainstream chat apps.

And of course there are usability improvements to GPG, being made by third parties: Debian introduced package verification a couple decades ago, Github does commit verification, etc. What's to stop e.g. Nautilus or Dolphin from introducing similar features?

[1]: https://man.openbsd.org/signify

◧◩◪◨⬒⬓
6. Y_Y+mu1[view] [source] 2025-01-04 17:13:32
>>rollca+1m1
> Then why no such efforts are being pursued for PGP(GPG) nowadays?

I wonder why there aren't more, but there are some, for example Proton's efforts towards encrypted email.

https://proton.me/support/how-to-use-pgp

(I won't mention the relative shortcomings of HTTPS and E2E chat apps here.)

[go to top]