
Why doesn't the Python package manager (PIP) have package signing feature? - el_programmador
https://dev.to/prahladyeri/why-doesn-t-the-python-package-manager-pip-have-package-signing-13ll
======
javagram
It would be nice if package managers would not only support 2FA, but make it
available via metadata the uploader and whether the uploader used 2FA.

If operations are performed over HTTPS, this would probably provide even more
security guarantees than the typical use of signatures. Organizations or
persons that want increased security could refuse to use packages that weren’t
uploaded with 2FA (which, yes, would include packages from automated build
servers which are often targets of hacking).

I imagine most people would trust-on-first-use signatures and then also accept
changes to the signing key, so how much security does it really give?

~~~
payne92
> It would be nice if package managers would not only support 2FA, but make it
> available via metadata the uploader and whether the uploader used 2FA.

How would this work when the package manager can be run by anyone?

2FA is an authentication method (akin to asking for a password, albeit a
special one). It's _not_ a digital signature.

~~~
javagram
It would work if you have a centralized registry with a centralized
authentication (like npm does, or maven central).

You’re correct that it’s not a digital signature. You have to be able to trust
the registry (whose communications to you are signed, via HTTPS).

~~~
eru
That would be pretty annoying.

The signatures are an end-to-end thing. As long as you can trust the signer at
time of signing, you can trust the package. No matter what happened to that
package in the meantime, or what shady people were in charge of transmitting
it to you. Be that five minutes after uploading or fifty years.

2FA and HTTPS only do anything extra on top of that for you, if you trust the
whole chain of transmission at all times, and all custodians of the data.

Adding 2FA and HTTPS might still be a good idea as a second line of defense.
But it's not a replacement for signed packages.

~~~
javagram
If the signer puts their key on a build server and that build server is
hacked, then the signing is worthless. (Although, having written this, I
suppose people would just put their TOTP secret on the build server also)

With a centralized registry model I already trust the registry anyway. It’s
not like I’m typically going out and verifying people’s keys by emailing them
to check what their real key should be or whatever.

~~~
eru
You are right about some of the complications.

You'd want
[https://en.wikipedia.org/wiki/Reproducible_builds](https://en.wikipedia.org/wiki/Reproducible_builds)
for a clear relation between source and artefacts. Then build-server hacking
would be slightly less problematic: at least anyone would be able to check
whether the server had produced any compromised builds.

And you could have multiple independent entities producing builds in parallel
for your open source projects that need to agree. So a hacker would need to
take control of all of them.

(You don't need to figure out byzantine fault tolerance or something like
that: if there's any discrepancy, sound the alarm bells and have humans
investigate.)

Every build server would sign their artefacts, but the signature would just
certify that some specific sources compile to some specific artefact. Not that
the sources are trustworthy.

Now you need to trust: the author of the sources of the packages at the times
of signing, and that at least one of the all agreeing build servers that you
ever collected signatures from for the package was not compromised at the time
of signing.

That signing build server doesn't even have to be the same server that build
your binary packages, the latter could be run by Satan for all you care.

Yes, in practice you will trust a central registry. The benefit of the
signature model is that you don't have to trust the whole chain of provenance,
but only at specific points in time.

------
CogitoCogito
That blog post provides nothing of value. It complains that there isn´t
package signing and that´s it. It doesn´t propose anything.

In the comments the author claims removing the signing is "beyond logic" even
while linking to a reddit thread in which the logic is laid out clearly. For
example:

[https://caremad.io/posts/2013/07/packaging-signing-not-
holy-...](https://caremad.io/posts/2013/07/packaging-signing-not-holy-grail/)

[https://mail.python.org/pipermail/distutils-
sig/2018-March/0...](https://mail.python.org/pipermail/distutils-
sig/2018-March/032066.html)

[https://old.reddit.com/r/Python/comments/8r9qby/pypi_has_rem...](https://old.reddit.com/r/Python/comments/8r9qby/pypi_has_removed_pgp_signatures_of_package/)

Read those links if you are curious, but I would recommend skipping the post
linked by el_programmador.

Read

------
sametmax
The recommanded way to upload a package on pypi is to use twine:

Https://pypi.org/project/twine/

Which does the signing as well.

But I don't know if pip checks it.

~~~
el_programmador
pip doesn't check anything. As the top reddit comment quotes from the github
issue:

>> This isn't a bug, we've purposely de-emphasized PGP on Warehouse. While we
support uploading them still and they're still a part of the API, we're not
exposing them to the user in the UI.

