-----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----- _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
