Signing built RPMs or how to create signed RPMs.

[Christos Triantafyllidis]

Hi Jesse,
   thanks for these clarifications, actually what Josh already written in his last mail was more or less what i wanted to see. I'm glad that you have such a mechanism for secure "online" signatures already in place. Thus i'll just copy setup/idea and then try to make it fit my needs. :).

   I just got a little bit disappointed in the thought of "we automatically sign whatever gets out from our koji" on an online machine (so why not the koji itself) and have consumers trust that this "build by Fedora based Fedora's SCM". What Josh and you described are totally fine for me.

Thanks again,
Christos

On Dec 14, 2010, at 8:26 PM, Jesse Keating wrote:

> On 12/14/10 5:20 AM, Christos Triantafyllidis wrote:
>> Hi Josh, all,
>> 
>> i'm reading this thread and i think that i've missed some point. What
>> is the purpose of signing an RPM if you sign it on an online machine?
> 
> The purpose of the signature is to provide something downstream 
> consumers can check to ensure that the build came from a Fedora source 
> control and the Fedora build system.  We don't intend our signatures to 
> provide anything beyond that.  The "online" machine in question is very 
> secure, as secure as we can reasonably make it with open source tools. 
> I'm not aware of a reasonable way to feed hundreds of thousands of rpms 
> into an /offline/ machine to sign them, and then cart all of them back 
> /off/ the offline machine and back onto a network.
> 
> Our package store, many TBs large, exists in a datacenter where the only 
> access is remote.  This is a fact of our infrastructure and one that we 
> have to deal with.  Creating sigul as Josh described is our effort to 
> secure the process as much as possible, while remaining a open project 
> that provides access to more than just Red Hat employees.
> 
>> I haven't seen the sign_unsigned.py source yet but i guess what
>> should be there is a mechanism that should download the unsigned
>> RPMs, then a manual operation of RPM sign (possibly on an offline or
>> at least access restricted node), and then another script to import
>> the signed RPMs (or just the signatures).
> 
> You really should start reading the sources then.  You've basically 
> described how sigul and sigulsign_unsigned works.
> 
> The sigulsign_unsigned script takes in options and data such as what 
> builds to sign, or what koji tag to sign, and what key to use.  It will 
> prompt you for your personal passphrase for a particular key (every user 
> has their own, nobody knows the real key passphrase).  This data is 
> passed along to the sigul bridge which is semi-restricted.  The bridge 
> operates against our account system to validate user certs, and with the 
> "vault" which is a very secure and limited access machine where the 
> actual gpg keys live.  The bridge fetches the unsigned rpms, passes them 
> to the vault.  The vault signs them and passes back the signed header, 
> which the bridge will import into koji.
> 
>> 
>> Am i seeing this from a wrong perspective? does Fedora really sign
>> the RPMs online? I guess this gets even worse if the sign operation
>> is done more efficiently, automatically after each koji build.
> 
> If "online" matches the above, then yes.  And we are moving to a point 
> where we can sign each package as it completes a build in koji.  The 
> only "worse" part is that we'd have one more extremely limited access 
> machine with cached credentials to a "buildsystem" key so that it can 
> detect a finished build, enact a sign+import of said build.  As I stated 
> before the GPG key is only intended to validate that the build happened 
> in an "official" way on "official" Fedora resources.  Nothing beyond that.
> 
>> I hope i don't sound offensive, but these were my thoughts as i
>> want/need to implement something like this in our local koji
>> installation and i hoped that you were using something more
>> sophisticated.
> 
> 
> -- 
> Jesse Keating
> Fedora -- Freedom² is a feature!
> identi.ca: http://identi.ca/jkeating
> 
> 
> --
> buildsys mailing list
> buildsys at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/buildsys
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3330 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/buildsys/attachments/20101214/8ee3b44e/attachment.bin