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.
      • User:jkeating I agree that different rpm keys per release would make it easier to retire keys as they are no longer used, however by the time content has "expired" we're no longer really supporting that content, nor encouraging its use. I think the tradeoff we get for less complexity is worth that. Even if we did different keys per release, if a key got compromised it is extremely likely that all active keys were compromised so we would have to change every active thing anyway, so I don't think having multiple keys actually helps there. Key signers will no longer know the passphrase which was one reason why we had multiple keys, to compartment passphrase knowledge.
    • 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?
      • User:jkeating I think F10 and above support repodata signature checking. We just haven't been in a good position to sign the official Fedora repos. That has largely been waiting on an ability to automate signing of content without having to punch in a passphrase.
• 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?
  • User:jkeating Hrm, that's a good question. Things would be more simple if we just used a single gpg key for any tagged build from Fedora's Koji. EPEL is a Fedora project, ergo it is not unreasonable for their content to be signed with the Fedora Project build key.

Note, there is a Koji ticket requesting integrity-protected downloads of Koji packages, which is addressed by this proposal. Mattmccutchen 06:57, 21 May 2010 (UTC)