donaldstufft's comments

It is true that an unverified TLS session does prevent passive attacks it does not prevent against "active" attacks. The general consensus is that it's not a useful property to differentiate passive from active here, since every passive attack can be upgraded to work as an active attack, on top of the fact that explaining the subtle differences to people is extremely difficult (and since they can be upgraded to active attacks, not worth it).

I wonder if the domain being `blog.pypi.org` tipped them off?

Assuming of course that the other attacker doesn't just MITM the first attacker.

But this is a very silly threat model, "I want exactly one person to be able to attack me at a time".

With self signed certificates your ISP can just serve their own self signed certificate, and then inject ads into the recipe blog.

I don't believe they would.

Looking at the top 20 packages in the last month by download (packages with hundreds of millions of downloads), only 1 of them shipped a GPG signature with their most recent release. I haven't asked the author of that one, but I do know them and I suspect they agree with the idea that it's not a valuable thing and they do it largely because it exists.

The problem with TOFU is that it assumes long lived keys (itself a bad practice) OR it assumes that the end user will be fine with regular notices that the keys that have signed their packages have changed, and will be able to correctly differentiate false positives from real positives.

Nobody at PyPI is opposed to package signing, and removing or minimizing the damage that compromised infrastructure can do.

However, GPG is not a good tool to build those features on top of, and the vestigial support for GPG signing that PyPI had in no way aided the long term efforts to get proper, secure package signing into PyPI.

Removing security features that don't work is a separate concern from making security features that do work. Nobody who has done any serious work on PyPI security in the past 15 years thinks that GPG will play a part in the future of PyPI security. It's support was entirely vestigial, served no practical purpose, and never would.

2005, https://github.com/pypi/legacy/commit/600f9383f8e7e0a2e60860...

Also, minisign, signify, sigstore are all much better than gpg for the problem of signing packages.

GPG/PGP is worse than nothing, because it provides an illusion of security in the majority of use cases unless you build significant infrastructure around it to the point that you're really just using it for access to it's crypto primitives.

GPG's Web of Trust cannot answer the question of who is trusted to sign for a particular package on PyPI. At best it can tell you that a key that is signed by someone whose key you've signed. That is not a meaningful security control. Practically nobody is signing GPG keys thinking "would I trust this person to sign for every package I might ever want to download" and they are instead at most trying to verify the identify on the key matches.

It's existence creates a bunch of people who insist in trying to take up the oxygen in the room anytime serious security design is trying to happen to try and shoehorn gpg in places where it has no business being.

Because the existing tool does a bad job at all of them, and those tools do reasonably good jobs at each of their respective tasks.

Fundamentally the things you want from a secure crypto system differ depending on the context in which you're applying it. Email needs different things than package signing does than file encryption does. It's silly to pretend that the same tool can provide a good and secure experience for all of them.

gpg signatures are not, and have never been a meaningful "best practice". The only secure package signing schemes that have ever used gpg signatures, uses gpg as a mechanism to access crypto primitives and has built their own secure system on top of it.

They're using gpg in spite of its features, not because of them, and would almost certainly be better served by using something else.

If people want checksums, it seems like it would be better for everyone around to just use checksums? If you just want to make sure that some file hasn't changed, that's a much better primitive for that then signatures.

To me the most interesting part of the article is whether or not the current signatures are even capable of being validated or not, which the answer to that is > 50% of them are not, and those are of the people who care enough in the last 3 years to still be using this undocumented feature.

Is it possible to build a secure signing system ontop of GPG/PGP? Sure. But doing that requires working around or eschewing so many features from it that you might as well just use the base primitives yourself rather than being tied to GPG/PGP.

How is checking for null any different than checking for the right type in general in TOML?

There's not a singular thing at fault.

Though there is nothing inherently free or decentralized about "PKI", and given your conflation of those concepts I suspect that you're not actually aware of where the lines are drawn from.

Certainly the decentralized nature of PGP adds some challenges to good usability.

However, a large number of the problems come from the PGP spec itself (some of which is defensible in a 20+ year old spec, but not in anything in a modern system) and from GPG's poor implementation.

Debian is basically the reason we didn't delete PGP signature support in 2018, because in theory some handful of Debian packages might be better off with this support.

In practice I think the handful of packages that this happens on isn't particularly meaningful or valuable, and in my experience what happens when Debian finds a new key signing packages is.. highly variable. I've seen them just disable signatures when a new key shows up (on major packages even), I've seen them just blanket copy whatever the new key is, I've seen them look at release notes for what the new key is. In one or two cases I've seen them actually track down the project and ask for verification of the new key.

To me, the PGP support in Debian's uscan feels more like security theater than actual security controls, given my experience with the varied responses to a new release being made by a different key.

> A bullet proof HOWTO can fix all of this

You cannot document your way out of a usability nightmare.

To my knowledge, everything in the Python packaging ecosystem that supports PGP signatures, does so by shelling out to the `gpg` command. Presumably gpg should be implementing the spec properly.

Not really, none of those things are things he is suggesting PyPI should do, but rather social expectations that come from being a maintainer of a large project.