Talk:Koji Build Autosign Proposal

• markmc Yay! (is that helpful? :-)
• toshio I like the idea of autosigning what comes out of koji so everything is signed.
• toshio So what happens when this single signing key is compromised?
  • User:jkeating We create a new key, and start resigning things for the active releases. Ideally we'll be signing repodata by then too with keys that do change per release which can mitigate issues with existing repos.
    • toshio Ugh. Do we have a method for removing the old key from the end-user's rpm databases? Do we have a better method for doing a mass resigning and re-push than last time? We only got around to resigning one release last time. Now we could potentially have four (Two released streams, a set of packages that have branched and are in beta, and rawhide -- we could have more if we also need to resign EPEL packages).
    • toshio I wasn't happy that we only resigned the active releases last time as users are using the inactive releases even though we tell them not to. Changing to a per release key made things potentially more secure as we could discard all copies of keys for an EOL release which makes it impossible to steal the key (or put them in offline/paper storage which still makes it harder). I don't get a good feeling from going back to a single key.
    • toshio I agree that signed repodata is a good piece of mitigation. But that requires that the active releases have a version of yum that checks the repodata signature. What's the plan there? Can we make implementation of this proposal for a specific release block on usability of signed repodata on that release?

• toshio Are we going to keep the resigning infrastructure running so EPEL can sign packages with a separate key or will we sign everything with the same key?