Am 05.02.2013 21:23, schrieb Donald Stufft: > * Do we have bindings to GPG that we can use? > * If not are we going to depend on users to install GPG? > * GPG installation can be tricky, especially for someone new to > programming.
Linux and BSD come with GPG installed or easily available. We are going to need some installer, bundle or good docs for Windows, though. I don't know about Mac > * What's the purpose of enforcing an upload to 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 PyPI as well as all downloaders need to retrieve the key somehow. PyPI should verify the signature after upload. IMHO public key servers are logical places to store the key. > * Expecting the user to decrypt the mail manually is kinda unfriendly > * Probably should include it as a file or something and just have > them pass it into a command on their computer like pyverifycreds < > file The key server and this step are modeled after launchpads handling of GPG keys. Of course an attached file would work, too. > * 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. PyPI signing buys us the confidence that the signature and package metadata can't be compromised. This protects us from breakins into PyPI and rogue admins (sorry Noah *g*). The signing process can be offloaded to a heavily secured machine. It makes the case "maintainer is removed from package but old signatures are still trustworthy" easier (see below). A PyPI signature may also be sufficient for users that don't want to verify the key of every uploader. > * 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). That's a good idea. How does the process work? Does one developer create + sign a file, sends both to the other developers and they add their signature? A project owner may set a minimum number of signatures for their project. The setting can be evaluated by PyPI and/or the download tool. > * 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? I have to think about it. At least you have to retrieve and acknowledge the new key. > * Similarly what if an owner removes a maintainer? Same as above IFF the owner decides to remove the signatures of the user from the package, too. In most cases the old signatures should be valid as the user was a valid maintainer at that time. If the user is rogue or the account compromised than the owner can decide to remove the old signatures, too. > * I think it should be a separate key ring. I agree. > 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 think it's ok to assume that during the initial contact PyPI is a good > faith actor. Users must have faith into PyPI. For example an evil PyPI may decide to hide an important security fix. Christian _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
