←back to thread

72 points harporoeder | 5 comments | | HN request time: 1.076s | source
1. bjornsing ◴[] No.41874067[source]
Does it matter much if the key can be verified? I mean it seems like a pretty big step up security wise to know that a new version of a package is signed with the same key was previous versions.
replies(1): >>41874734 #
2. woodruffw ◴[] No.41874734[source]
> I mean it seems like a pretty big step up security wise to know that a new version of a package is signed with the same key was previous versions.

A key part of the rationale for removing PGP uploads from PyPI was that you can't in fact know this, given the current state (and expected future) of key distribution in PGP.

(But also: yes, it's indeed important that the key can be verified i.e. considered authentic for an identity. Without that, you're in "secure phone call with the devil" territory.)

replies(1): >>41877913 #
3. bjornsing ◴[] No.41877913[source]
> A key part of the rationale for removing PGP uploads from PyPI was that you can't in fact know this, given the current state (and expected future) of key distribution in PGP.

I find that hard to believe. The public key or at least its fingerprint should be in the signature itself.

replies(1): >>41879638 #
4. woodruffw ◴[] No.41879638{3}[source]
The fingerprint is always in the signature (when the signature packets are well-formed). The public key is almost always not. I think it would behoove you to read the post linked in TFA, which explains this in detail[1].

[1]: https://blog.yossarian.net/2023/05/21/PGP-signatures-on-PyPI...

replies(1): >>41903077 #
5. bjornsing ◴[] No.41903077{4}[source]
In general in Software you have to start with an idea of what you want to accomplish. Then you have to break that down and determine what is feasible within the constraints you are working. Ideally you then point out the constraints that are limiting your solution. I feel like all of that is missing here. All I can see there is just an immense sea of details.