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

[Seth Vidal]

On Fri, 9 Apr 2010, James Laska wrote:

> 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?
>


I know this is a side issue - but the above is an excellent argument for 
signing all pkgs that come out of koji with a 'yep this came from koji' 
key - and only signing our repository w/the fedora sig.

-sv