[Catalog-sig] [Draft] Package signing and verification process

[Zygmunt Krynicki]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

W dniu 05.02.2013 21:23, Donald Stufft pisze:

> * Do we have bindings to GPG that we can use?

There are some gpg bindings but my visibility is limited to Linux
world. GPG wrappers that talk to it using standardized input/output
format exist if you google enough but deserve a proper project
probably. I myself am blocked by lack of such proper bindings.

> * If not are we going to depend on users to install GPG? * GPG
> installation can be tricky, especially for someone new to 
> programming.

If you take GPG out of the picture then the system is pointless IMHO.
If you look at how apple handles virtually identical situation you
will realize that they have a keyserver and key revocation authority
but each user has a keyring that he chooses to trust each time he
installs something. GPG is perhaps ugly but the concepts are essential.

You must either:

1) Trust the gatekeeper - signed repository mode
2) Trust each developer - random tarball + .asc mode
3) "don't worry, be happy", trust everyone - pypi / gem / windows
users running unsigned executables

Once you pick 1-3 then you can improve the user experience. We cannot
trust the gatekeeper as pypi is not a gatekeeper of any kind. We
really must choose 2 and polish what can be polished, accepting the rest.

> * What's the purpose of enforcing an upload to a keyserver?

Because that's the common good practice, pypi should not be a keyserver

> * If we are trusting the fingerprint someone is sending us we can
> trust the public key they are sending us, * Adds an extra step to
> go from zero to releasing * Expecting the user to decrypt the mail
> manually is kinda unfriendly

It provides a guarantee that the user has access to the public and
private keys and completes the email cycle. Launchpad.net has the same
functionality built in.

> * Probably should include it as a file or something and just have 
> them pass it into a command on their computer like pyverifycreds <
> file * I don't think PyPI signing things buys us anything here. If
> the package exists on PyPI we can assume either PyPI allowed it, or
> PyPI is no longer a good faith actor (e.g. compromised), if the
> latter occurs there's not much to stop the attacker from signing
> their own file. * Tor / TUF both have the concept of not only
> multiple keys being allowed to sign a release, but also a required
> # of keys to sign a release (prevents a rogue maintainer or a
> single stolen key).

This feels equivalent to the key revocation problem.

Users need to securely/with confidence update their trust requirements
for a particular project. It might also lead to some interesting
corner cases. What if a project having two developers requires both to
sign each release but one of the pubic keys is lost. For the sake of
argument let's assume the revocation certificate was not lost and the
key is properly revoked. How can those developers securely inform
their downstream recipients that a new key was added to the trusted
set and the old key was removed.

If weaker rules allow users to change trust requirements then those
are equally worthless (rouge developer / compromised key owner can
issue trust update that effectively nullifies current settings).

I get the feeling that we either put a lot of trust in the central
authority (pypi) or we must conclude that peer-to-peer trust without
automatic update methods is the only way that prevents us from some
attacks.

> * What is the expected end user reaction if someone revokes their
> key from PyPI? In other words if I've established a trust with key
> A, and the maintainer revokes that what happens when I try to
> install their package now with key B? * Similarly what if an owner
> removes a maintainer? * I think it should be a separate key ring.
> 
> In general I think any system that depends on PyPI* to handle trust
> is going to not gain us what we're hoping for. This needs to be
> designed in a way that we assume PyPI is no longer operating in
> good faith. If we do require PyPI to still be on our "side", then
> we're only concerned for MITM and SSL should be enough there (Not
> as currently configured on PyPI though).

I agree. I think that pypi should not have to be trusted. Real people
trust other (few, limited) real people. We don't normally trust large
bodies (corporations, groups) as that trust cannot be effective.

> * I think it's ok to assume that during the initial contact PyPI is
> a good faith actor.

Yes although it depends on proper MITM defenses, CA trustworthiness
and lastly, for paranoid users and special cases, it should be
configurable.

Evil people can use pypi as well, it should not be implicit.

Thanks
ZK
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJREXmTAAoJECiU6TooxntHDDoQALAMmwP9irh1XNFqgoZnHntg
NLniVCdqKFOl6SsObGEfRlGVSr9yQtq4QQAxo8B1HFjxyFJEfl8XKEp9FKRWZXnn
vsdUEDvAWgIjnJA5yZkYLmHoO/4BHCDMPzy3OMOfg4vdqOu9/0DqDceTLVQdTWjp
etQMXpia+IbgTny/MUl6Hy1eZMtzaTyGbHy4iUXIbXp8Ca0TqxzYSpAtRdxkP7V2
WcjoytI9BPG/6p3sshykhzAYy4ZoxlzaMKFYTAhOK0FSPM5NnQ/R3y6rDEA8IoIq
2FYqxpTO2PVQgOQFdGRDMCk2i1aLA9iH9goRZZmBziUfI6seydp9dygG7GRhLsgB
XGno3Fot6Z/FM0slH+ZEtYFwz5HslVSYJ5kjswF73HIbDFkLzKYjC/3hkm4LhE+Z
3f5j4HkkLyUs3DnrUyLWhuv/ceWmQEP43v+k3a45pShzknkKqSi9zsopcUjPNcJx
6BFkKBqU1JXN+w9EtmJ/L+A5G9sukvV1lOjFMrP65/a68urItT06cJy3fVDImb2f
4dRr/DhIS1mt2nJi1cph48wkd+mEybhouB63RVNvwSgkyaFuAVBybPLWV+XOy72t
b06WZylW08VVwKWWUCbCSy5Q9hKFCkEiYEq8arArHsyVkyDwcP5wWjb+8e0FL6tS
D+wG3z3iLLjDo9vuZHNn
=dBYC
-----END PGP SIGNATURE-----