Conversation

twitter.com/mjg59/status/1 GPG's entire keyring and trust model is awful, far beyond this issue. As a whole, the software is overly complex with far too much attack surface and poor usability. Even using it for something as simple as verifying a file with a specific key is arcane.

Quote Tweet

Matthew Garrett

@mjg59

Jun 29, 2019

This (from gist.github.com/rjhansen/67ab9) is just genuinely awful. There is nothing new about this attack. It demonstrated nothing unexpected. The time to tell people to stop using infrastructure is the moment you know it's vulnerable, not after someone's taken advantage of it.

Text reading "At present I (speaking only for myself) do not believe the global keyserver network is salvageable. High-risk users should stop using the keyserver network immediately."

read image description

ALT

Replying to

Raised that issue with SKS community a few times (bitbucket.org/skskeyserver/s, gitlab.com/yegortimoshenk), along with a few others, including trivial DoS and ability to add arbitrary information like UIDs or revocations to their web UI since none of it is cryptographically verified.

Replying to

and

Ended up getting legal threats off-list to my email address for full disclosure, nothing has been fixed year in, SKS maintainer believes that displaying users invalid data isn't a problem, since they should verify all of this on their computer anyway (!): bitbucket.org/skskeyserver/s

Replying to

and

This is a good example of overall policy from GPG community in general: blame user for doing things wrong, which seems to be the source of usability issues.

Replying to

and

OpenPGP is currently standard and that's a major reactive force. If Git was to support signify/minisign, that could very well allow people to switch. And for people who want secure asynchronous messaging, well, there is puncturable encryption (youtube.com/watch?v=DjGxYw).

youtube.com

Forward Secure Asynchronous Messaging from Puncturable Encryption

Forward Secure Asynchronous Messaging from Puncturable EncryptionIan MiersPresented at the 2015 IEEE Symposium on Security & Privacy May 18--20, 2015 ...

Replying to

and

Git signed objects are insecure, regardless of which mechanism is used for signing. It only provides verification of a node in isolation (commit or tag), not everything it references. It ends up depending entirely on the sha1 hash chains which can't be considered secure anymore.

Replying to

and

I'm inclined to stop signing tags because it's increasingly becoming security theatre. There's also the issue of Git exposing substantial attack surface before the signature is verified. Compare verifying an external signature on an archive to handling all these objects first.

3:33 AM · Jul 1, 2019Twitter Web Client

Replying to

and

It's definitely far more secure to verify the signature on a source archive, including one with a Git repository inside it. It might be advisable to switch to providing those. I could definitely provide at least as much security as Git by signing a manifest with signify though.

Replying to

and

The stable release manifests could be changed to reference commits by hash instead of by tags, which would then be able to provide at least as much security as verifying signed tags. Either way, it depends entirely on sha1, which isn't comforting at all. I want a proper approach.

Show replies