On 2 January 2015 at 11:21, Donald Stufft email@example.com wrote:
To be clear, there is zero delay in being able to publish a new project, the delay is between moving from a new project being validated by an online key to an offline key.
OK, got it.
Although on the terminology front, I don't really understand what an "online key" and an "offline key" are. My mind translates them as "worse" and "better" from context, but that's about all. I'm not asking for an explanation (I can look that up) but as terms being encountered by the non-specialist, they contribute to the difficulty in reading the proposals. If there's any better way of naming these two types of keys, that would be accessible to the non-specialist, that would be a great help.
(Actually, the other implication I read into "offline key" is "something that I, as the owner, have to take care of and manage" - and that scares me because I'm rubbish at managing keys or anything like that, basically anything more complex than a password - at least until we get to things like RSA keys and tokens that I use for "work" and am paid to manage as opposed to "hobby" stuff).
The only real difference between validation levels is that until it's been signed by an offline key then people installing that project are vulnerable to someone compromising PyPI. This is because until the delegation of project X to a specific developer has been signed the "chain of trust" contains a key that is sitting on the harddrive of PyPI.
However, once a delegation of Project X _has_ been signed changing that delegation would need waiting until the next time the delegations were signed by the offline keys. This is because once a project is signed by an offline key then all further changes to the delegation require offline signing.
"Delegation" is another term that doesn't make immediate sense. I read it as "Confirm ownership" sort of, Again, it's not that I can't work out what the term means, but I don't get an immediate sense of the implications. Here, for example, it's not immediately clear whether delegation changes would be common or rare, or whether having them happen quickly would be important. (For example, if you're not available for a pip release, and we never bothered sharing the keys because it's easier just for you to have them, would we need a delegation change to do an emergency release?)
Again, this isn't something that it's important to clarify for me here and now, but I would like to see the PEP updated to clarify this sort of issue in terms that are accessible to the layman.
In addition, this does not mean (I believe! we should verify this) that the owner of a project cannot further delegate to other people without delay, since they'll be able to sign that delegation with their own keys and won't require intervention from PyPI.
See above - implies to me that if the "owner" (in terms of keys rather than project structure) is unavailable, other project members may not be able to upload (rather than as now, when they can upload with the project's PyPI account password and/or standard password recovery processes to the project email address).
So really it looks like this (abbreviated, not exactly, etc):
root (offline) |- PyPI Admins (offline) |- "Unclamined" (online) |- New Project that hasn't yet been signed for by PyPI Admins (offline, owned by author) |- Existing Project that has already been signed for by PyPI Admins (offline, owned by author)
I'm not keen on the term "unclaimed". All projects on PyPI right now are "unclaimed" by that usage, which is emphatically not what "unclaimed" means intuitively to me. Surely "pip" is "claimed" by the PyPA? Maybe "unverified" works as a term (as in, verifying your account when signing up to a forum). I get the idea that unclaimed implies there's a risk, and sure there is, but this smacks of using a loaded term to rub people's noses in the fact that what they've been happily using for years "isn't safe". This happens a lot with security debates, and IMO actively discourages people from buying into the changes.
It would be useful to have some document (or part thereof - maybe an overview section in the PEP) structured as an objective cost/benefit proposal:
There are probably at least two classes of reader involved - project authors and project users. If in either case one class of user has to bear some cost on behalf of the other, then that should be called out.
I believe that I (and any other readers of the proposals) should be able to sensibly assess the cost/benefit tradeoffs on my own, given the above information. My experience and judgement may not be typical, so my opinion should be taken in the context of others, but that doesn't mean I'm wrong, or that my views are inappropriate for me. For example, in 20 years of extensively using software off the internet, I have never once downloaded a piece of software that wasn't what it claimed, and I expected it, to be. So the discussion of compromising PyPI packages seems like an amazingly low risk to me.
The periodic signing process by the PyPI admins just moves a new project from being signed for by the "Unclaimed" online key to being signed for by our offline keys. This process is basically invisible to everyone involved.
It's as visible to end users as the significance of describing something as "unclaimed". If nobody cared a project was "unclaimed" then it would be invisible. Otherwise, less so. Hence my preference for a less emotive term.
Does that make sense?
Yes it does - many thanks for the explanation.
 That's just an example, and it would be off-topic to debate the various other things that overall contribute to why and to what level I'm currently comfortable using PyPI. And I'm not running a business that would fail if PyPI were compromised. So please just take this as a small data point, nothing more.