New package gpg signature acceptance test (was Latest FC13 kernel rejected as unsigned)

[James Laska]

On Fri, 2010-04-09 at 11:00 -0400, Bill Nottingham wrote:
> James Laska (jlaska at redhat.com) said: 
> > On Fri, 2010-04-09 at 08:38 -0400, Bill Davidsen wrote:
> > > The rpm kernel-2.6.33.1-19.fc13_2.6.33.1-24.fc13.x86_64.drpm downloaded, then it 
> > > looks as if it created an rpm by applying the delta and decided the rpm wasn't 
> > > signed? And there's also an rpm kernel-2.6.33.1-24.fc13.x86_64.rpm, which I 
> > > assume is the rpm created by the delta.
> > > 
> > > Is this some download error, or is there another problem with unsigned packages 
> > > getting into the repos? I did repeat the download, same CRC...
> > 
> > Seems worthy to add a package acceptance criteria to the Package Update
> > Acceptance Criteria [1] similar to the following:
> > 
> >       * Packages must be signed with a valid Fedora GPG signature
> > 
> > I guess one could argue that the existing criteria "Packages must be
> > able to install cleanly" would include valid signatures.  But it doesn't
> > hurt to be specific here.  
> > 
> > Comments/concerns/ideas?
> 
> The process flow is:
> 
> 1. package is built in koji
> <any delay from maintainer>
> 2. update is submitted in bodhi
> <delay until next push>
> 3. package is signed
> <then nearly instantaneously>
> 4. package is pushed

When you say "package is pushed", do you mean pushed to the requested
repo (updates vs updates-testing)?

From a user-perspective, having to use --skip-broken seems just as bad
as using --nogpgcheck.  But if I understand correctly, given the
workflow above we don't have a mechanism to enforce this in the QA
space?

Thanks,
James


-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20100409/48e84a96/attachment.bin