Sign PyPI Releases

[maltfield]

Describe the bug

When a user downloads this python module using pip, there is no cryptographic authenticity or integrity validation to protect the user from a MITM attack.

Therefore, this project is making any other projects that obtain the netaddr module via pip in their build process vulnerable to a watering hole attack.

Expected behavior

Users should have a mechanism to cryptographically verify the integrity and authenticity of netaddr when obtaining it through pip.

To Reproduce

pip install netaddr

Additional context

Possible solutions include:

1. Using the --sign argument of twine when uploading packages to PyPI

2. Publishing a cryptographically signed document (ideally using gpg) listing the hashes for all packages uploaded to PyPI, which users can then pass into pip using the --hash argument

[jstasiak]

Hey @maltfield,

Where would you get the hashes and/or the public key that you can use to verify a signature from? How would you trust the hashes and/or the public key haven't been tampered with?

Forgive me for being blunt, I've read several discussions on the subject and I'm yet to hear a convincing argument about signed hashes like this doing more than just moving the trust (with all the security implications) elsewhere. The cryptography is a non-issue as far as I understand, it's the key distribution that's the (unsolved) problem.

[maltfield]

How would you trust the hashes and/or the public key haven't been tampered with?...it's the key distribution that's the (unsolved) problem

PGP has been around since 1991. Rather than having one way to distribute your authoritative PGP signing key, there are many solutions to this problem.

Personally, I recommend that you upload your public key (or, at minimum, the full fingerprint of your key) to as many distinct domains as possible. For example:

1. your project's forge (eg github, gitlab, etc)
2. your project's personal website (if distinct from above)
3. https://keybase.io
4. The https://keys.openpgp.org key server
5. your project's offical communications account (eg twitter, mastodon, etc)
6. your project's other official social media accounts (eg facebook, youtube, etc)

By uploading your key to multiple distinct domains, you permit your end-users or downstream developers to obtain your key safely, as it's significantly less likely for an attacker to modify the key or fingerprint's contents or pull-off a MITM attack on 3+ distinct domains.

But that's just my personal recommendation. Many large organizations sign their releases with PGP, and some of them have written best-practices guides based on their experiences, which I recommend looking into:

1. https://riseup.net/en/security/message-security/openpgp/best-practices
2. https://infra.apache.org/release-signing
3. https://docs.opendev.org/opendev/system-config/latest/signing.html
4. https://wiki.debian.org/Subkeys

Please let me know if you have any other questions regarding how to generate a PGP signing keypair, safely distribute its public key, sign your packages with this key, and how to document the process for users to cryptographically verify your release's signatures for their authenticity and integrity.

[jstasiak]

I'm sorry, you seem to have assumed I don't know or understand all of those things (I do) while not really responding to my questions.

[maltfield]

Sorry, I'm not sure how the above explanation doesn't answer your question?