I support back signing the existing uploads. However, I would like to know if there would be a way for users to differentiate a retroactive signature from a “regular” one, which should strike a balance between initial usability and transparency.
I really like this idea. I think it is very possible using the delegation mechanism within TUF, so as to use a “backsigning key” for all the backsigned packages, and then move them to a regular “signed” role once they are pushed after the flag date.
I went ahead and closed the issue. If there are any objections I’m happy to reopen it.
I noticed that, over the course of the last several weeks, there’s been some back-and-forth about whether the PEP should include either or both of:
- a short review of how other package managers/ecosystems handle this threat
- a short list of other platforms/services that have integrated TUF successfully, and what benefits TUF has provided to them
In response to @tiran and to the conversation about mentioning Microsoft, @mnm678 updated the abstract to only mention “TUF has been used in production by a number of organizations, including use in Cloud Native Computing Foundation’s Notary service, which provides the infrastructure for container image signing in Docker Registry”.
Is this sufficient? Would people prefer more detail on adoptions? I think the current PEP draft does not include a short review of how other package managers/ecosystems handle this threat, or a link to such a review; is this something people would find helpful?
Of the points I raised, the following two remain outstanding with addition of the text you quoted:
- What benefits were gained from using TUF in those organisations?
- How do other ecosystems handle this issue (in particular, what alternatives to TUF have been used)?
but I’m not particularly inclined to make an issue out of it. If I were going to push for anything further, it would be a (brief) summary of what alternatives to TUF exist. Personally, though, I’ve probably got the context I need from the discussions here, so adding that sort of information would be only marginally useful to me, and I don’t really want to continue the debate solely on behalf of hypothetical readers who don’t have a feel for what TUF is.
For the original asyncio PEP, there was some additional background material that would have been a distraction in the PEP itself, so I ended up posting it on my blog.
In this case, I think we could reference the Linux Foundation blog post from when Notary and TUF were accepted as CNCF projects for general background info: https://www.linuxfoundation.org/cloud-containers-virtualization/2017/10/cncf-host-two-security-projects-notary-tuf-specification/