I’d rather have a discussion here that results in a PR, rather than responses to the questions being in a PR that I then either have to review on github, or spot the differences in the next revision of the PEP.
“Does not require” is not quite what I asked. Is there any option for package authors to do something different based on this PEP?
I guess the implication here is that PEP 458 is about server-side signing whereas PEP 480 is about client-side signing? Which prompts me to say that the title of this PEP (“Surviving a compromise of PyPI”) gives me no clue that this is what it’s about.
“Yet” worries me here. Either this PEP affects package authors or it doesn’t. There’s no “yet” about it. If what you mean is that a different PEP (480) affects package authors, then that is irrelevant to this discussion. It’s entirely possible that this PEP gets accepted but PEP 480 doesn’t. Or the other way around. Either way, this specific PEP needs to stand on its own and if it doesn’t affect package authors, say so clearly.
Not really, to me, sorry…
I think you’re missing the point - posting here isn’t to gather feedback that you can go away and address, it’s to have a discussion, where you engage with the community and come to a consensus about the way to address people’s concerns. As it stands, this PEP seems to have been developed largely out of sight of the community, and that’s what bothers me. Maybe no-one will be interested in having an extensive discussion, given that this is a pretty specialised proposal. But people should still be given the opportunity to engage, and discussions on a github PR in the PEPs repository isn’t, in my view, sufficient for that purpose.
In the interests of saying something about the actual proposal, rather than just about the process, I’ve just gone through the first part of the PEP, and I’ll add some comments.
The abstract does actually give a reasonable overview of what’s being proposed, as long as I take “implement TUF” as a goal in itself, and don’t ask why (there is more on why later in the PEP, which I’ll come to, though). But it does state that “This PEP does not prescribe how package managers, such as pip, should be adapted to install or update projects from PyPI with TUF metadata.” So you’d be perfectly happy if pip didn’t change, and continued to ignore the TUF metadata? That seems unlikely. Certainly I could imagine the PEP merely saying that installers should check the metadata (although I’d also expect a non-normative comment that the PEP assumes that pip will do this), but to merely say “we’ll do a bunch of work to add some metadata that no-one needs to use” seems to be going too far - or to look at it more cynically, to be avoiding the question of what the implications are for pip and other installers. One immediate question I’d ask is how much overhead, both in terms of speed and size of vendored libraries, this would add to pip. I think some idea of the cost to installers is entirely relevant to the PEP.
The motivation section adds some background, but I was somewhat confused by it. It talks about the wiki breach causing loss of data, but the description of how TUF would help PyPI doesn’t discuss data loss, it’s all about detecting (malicious) corruption, which is a different issue (albeit just as serious). So I was left feeling that while I agreed with the that doing something is warranted, I’d been subjected to some sort of “bait and switch” where the motivating event is unrelated to the proposed solution.
After this point, the PEP got too detailed for me, so I won’t go any further.