We talked about this a bit. I'll try and summarize what is needed.

1) Support in yum (done I think)
2) Adaptation to the bodhi push code to wait for signed repodata after mash
3) Agreement on the key to use, should just be the same as the one used to sign packages

I do have some questions.

A) How far back do we want to do this? I would venture F10 (if yum support is there) and forward.
B) If repodata is signed and yum doesn't support that (F9 for example), will things explode?
C) What timeframe are we looking for resolution on this? The milestone is set for F11 Final, but that might be pushing it given the bodhi code and repodata signing process aren't even started yet. Which leads to...
D) Is this something that can be phased into a release after it GAs?
E) Is this Feature worthy?

I hate trac formatting. Questions reformatted below:

{{{

A) How far back do we want to do this? I would venture F10 (if yum support is there) and forward.
B) If repodata is signed and yum doesn't support that (F9 for example), will things explode?
C) What timeframe are we looking for resolution on this? The milestone is set for F11 Final, but that might be pushing it given the bodhi code and repodata signing process aren't even started yet. Which leads to...
D) Is this something that can be phased into a release after it GAs?
E) Is this Feature worthy?
}}}

A) I think F10 is sufficient

B) It is a detached signature so if there is a too old ver of yum it just doesn't see the sig

C) unknown on the timeframe

D) except we might want to have the base repo signed.

E) Shrug

A) F10 would be fine. I suspect F9 will be EOL by the time this is fully rolled out.

C) ASAP. If it can't be done by F11 gold, so be it, but if it can, all the better.
D) to seth's point, we might just manually post signatures for the base repos for F11 gold, if bodhi and the rest of the automation aren't ready in time.
E) We could highlight it as such, but as it's a) conceptually simple from an end user POV, and b) way past the feature deadlines, that seems like extra overhead.

The push for this comes from a security paper published in February, noted here:
http://lwn.net/Articles/326817/
http://www.cs.arizona.edu/people/justin/packagemanagersecurity/

We have most of what we need in place already to mitigate all these vectors. The remaining ones include signing repomd.xml files, and getting https cert validation enabled in yum.

And just for the record "Security paper" is a better way of putting it.

Ok. For the bodhi code, we need a couple of things

1) A manner to wait for repodmd.xml.sig (or whatever we call it) to show up before finishing the push. We can probably reuse or copy the wait_for_sync function to do this in masher.py [[BR]]

2) The tricky part. Once bodhi is spinning waiting for the above, we need a way to kick off a sign run and get it imported to the proper location. Need to think about this a bit more. If people have ideas, feel free to chime in.[[BR]]

Should probably have Luke on this, since he is the bodhi-god.

This cannot be done for Fedora 14 due to bugs with the GOLD package versions.

Also, it seems like movement is toward signing with non-gpg. What should we do with this ticket? close it and re-open a new one when we're ready to try the new thing, or attempt to do a one-release of signed with gpg then change it for F16?

I say leave it open. If it's not GPG-signed, but some other method, fine by me, whatever can be made to work.

Unsolved problem: This will require manual intervention after a push was prepared, therefore delay updates.

requirement: credentials for sigul should not be stored in memory during the push

Question for the meeting: Is caching the sigul credentials still a no-go, considering that it also happens for the autosigner.

Discussed here: http://meetbot.fedoraproject.org/fedora-meeting-1/2014-09-08/releng.2014-09-08-15.41.html

Credential caching is not possible on update creation machines, because too many people can access them.

A concrete proposal is needed to move this forward.

Blocked on autosigning capabilities optionally being discussed as part of F25. Once that was available, additional work needed in either the script that syncs it or Bodhi to request the signing.

I have moved this to https://taiga.fedorainfracloud.org/project/acarter-fedora-docker-atomic-tooling/us/799