I came up with a key rollover scheme for the server key on PyPI. The objective of this key rollover is to protect against brute-force attacks of people trying to crack the key. If the main server itself gets compromised (and the private key leaks), this scheme will not help, and we will need to reset the package database back to a known-safe point in time.
The idea is this: At any point in time, two keys are known - the "current" key, and the "new" key, https://pypi.python.org/serverkey https://pypi.python.org/serverkey.new There will be a key rollover every year on July 1st. At this point, the "new" key becomes current, and a new "new" key is generated and published. Tools using the mirror infrastructure are encouraged to hard-code (cache) both keys in their code base, and attempt validation of a "simple" page against each of them. If both validations fail, either the keys are outdated, or the mirror they are using has been compromised. In this case, they should fall back to not using mirrors, but contact the master directly. After a key rollover, mirrors will need some time to refetch the signatures for all "simple" pages, so the old current key may be needed some time after the key rollover still. Within one day, all mirrors should have caught up. Also after a key rollover, tools should update their cached copies of the keys, and produce new releases. Users will then have one year to upgrade their tools to continue to use the mirror infrastructure. Tools may also chose to offer users to update the serverkeys (after due validation), or may chose to download them automatically, in which case they should validate the https server certicate for authenticity of the keys. The key rollover will be logged in the PyPI journal, using an empty package name and an empty release. TOOLS USING THE JOURNAL MAY NEED TO BE FIXED TO ACCOMMODATE EMPTY PACKAGE NAMES. Earlier today, such a journal entry was already added; I took it out again when I noticed that some tools actually do need to be fixed. Unless some flaws are detected in this scheme, I'll do the first key rollover this coming July. Regards, Martin _______________________________________________ Catalog-SIG mailing list [email protected] http://mail.python.org/mailman/listinfo/catalog-sig
