No PGP signature on 2.10.0 release ?

[ArchangeGabriel]

Normally we used to get the .asc file at https://files.pythonhosted.org/packages/source/h/h5py/h5py-2.10.0.tar.gz.asc, and but it is not available for this release. Is that expected?

[tacaswell]

attn @scopatz

[scopatz]

Sorry, this was missed. @tacaswell - how are these normally generated?

[tacaswell]

I use the --sign flag on twine when uploading the sdist. I normally only sign the sdist (and not the wheels) because that is what I generate on hardware I control. I think the asc file can be uploaded after the fact.

[scopatz]

Ok! Thanks!

[scopatz]

I think I need to do this on the machine I released from

[scopatz]

I am a little confused here. The asc files don't seem to be uploaded for previous versions: https://pypi.org/project/h5py/2.9.0/#files How can I verify that an asc file gets pushed?

[ArchangeGabriel]

Oh, I see, there is a new release manager. Hi @scopatz ! Don’t be sorry, I can guess it’s hard to get everything right the first time. ;)

Regarding your last question: they are never displayed by the UI at PyPi indeed. You have to try to download it using an URL like the one in my first post. For instance this works: https://files.pythonhosted.org/packages/source/h/h5py/h5py-2.9.0.tar.gz.asc. But the 2.10 one seems to still be missing.

[scopatz]

Ahh Ok! Great. So this should definitely work now with future releases that are done on rever v0.4.2+. I'll try to upload the v2.10.0 sig file later tonight

[takluyver]

@ArchangeGabriel : Are you actually verifying a signature from a specific key you trust? Or are you just verifying that the package has a valid signature from some key?

[ArchangeGabriel]

Until now I was verifying with @tacaswell key(s) since he was the one signing the release. I don’t have definitive trust in it (e.g. I did not met in person with him to check he was owning the key), but an “accumulated” one: the releases always matched his key(s), they are the ones available at https://github.com/tacaswell.gpg, etc.

[takluyver]

But if any of us can do a release, it could be a different key from release to release? There are 5 of us now with upload permissions - would you really be confident that we all handle our keys carefully enough?

My preference is not to bother with release signing. I've released quite a number of other Python projects without release signing, including some widely used ones, and it's not been a problem. My overall impression is that the number of people even looking at the signature is tiny, and no-one is actually handling it seriously enough to provide real security.

[scopatz]

That's pretty much my opinion of release signing. We can reduce this to non-blocking if we want.

[tacaswell]

I have been signing both h5py and Matplotlib for a few years now on the theory that it does not hurt anything.

The reason that pypi does not show the asc files is for exactly the reason that @takluyver says.

I recently changed keys to one that is on a yubikey so I am pretty confident that this one is secure.

[coderobe]

But if any of us can do a release, it could be a different key from release to release? There are 5 of us now with upload permissions - would you really be confident that we all handle our keys carefully enough?

Trusting 5 keys controlled by the members of the project is still more secure than not verifying at all.
Please don't stop signing releases

[shibumi]

Just an idea:
@ArchangeGabriel has already one of your keys in the keystore, that guy could sign all other developer keys and @ArchangeGabriel can then import all of your keys. That way you have a chain of trust and @ArchangeGabriel can trust all developers. And you can continue with signing each others keys.

[eli-schwartz]

My overall impression is that the number of people even looking at the signature is tiny, and no-one is actually handling it seriously enough to provide real security.

Well, Linux distributions generally want to verify signatures. In fact, we'd like to verify every signature we possibly can. And no, we don't "know" that upstream is responsible about this, any more than we know that the openssl or linux kernel signing keys are responsibly held... but that's not our job, our job is to put our faith in the people we've verified by various out of band methods to be the authorized upstream release managers.

The fact that the PyPI website developers don't believe people who write software using Python should care about security, is indeed a problem. But it doesn't fundamentally prove that we don't bother researching whose signatures we are trusting.

And even if we were blindly trusting signatures, there is still Trust-on-First-Use -- if you know that every release so far has been signed by a certain key (or a shortlist of keys), then you know the next release is signed by certain people (even if you haven't met them in person and cannot prove beyond all shadow of a doubt, who they are).

And even if those keys were to change often, it would still leave a paper trail of who has cryptographically signed each release. So this can be independently verified by third parties, and in a worst case scenario you might be able to finger "whodunnit", whatever "it" might be.
But, we will most likely pop up and ask "just double checking, is this guy authorized to release stuff, and if so can you e.g. sign his key".

It is... understandable, when some software still does not consider itself important enough to bother signing releases in the first place. Understandable, and regrettable. It is sad when people stop doing so, and if there isn't a good explanation (and even then, it's difficult to determine what is good enough), then it is also a highly alarming indicator that established security protocols have been mysteriously violated.

It's downright depressing for the entire software industry when software forges (PyPI) aggressively penalize the idea of security, removing people's ability to tell that there even is security to begin with, and encouraging people who used to care about security, to not care about security.

"But it doesn't matter because our metrics say that 99% of casual Windows users don't know what security is."

[anthraxx]

As i would just repeat the above again, i gently just ask if there is any update on this? Distros would highly appreciate to have a secured supply chain. The gain really outweighs.

[aragilar]

I think consensus is not enough of the maintainers have signing keys ready for this to be a reliable thing we can do. I guess if whoever does the release wants to sign it, they can, and they should have their public keys on their github profile so that the signature can be checked (i.e. each release is different)?

[anthraxx]

If every release is different in terms of some are not signed then there is unfortunately literally no point to sign some of them at all.

[takluyver]

PyPI has now ended support for PGP signature uploads. This was prompted by someone reviewing signatures uploaded in the last 3 years, the results of which make it clear that even if some people are trying to validate signatures, no-one actually cares about the keys they're signing with.

If you disagree with this move, I'd suggest you look into newer security efforts around PyPI. PEP 480 looks somewhat stalled, but there was at least some movement on it last year. And maybe hold back the snarky comments about casual Windows users, given that even most of the people still making PGP signatures in recent years weren't doing so with any verifiability.