QA process was Re: RPM submission procedure

[Stefan van der Eijk]

Toshio wrote:

>On Thu, 2004-01-08 at 14:05, Stefan van der Eijk wrote:
>  
>
>>Toshio wrote:
>>    
>>
>>>It took me a while to see this, but there really is a need for a two
>>>step QA/testing process -- at least when you involve an autobuilder:
>>>Pre-build:
>>>Check for trojans and compromise attempts.
>>> 
>>>
>>>      
>>>
>>This isn't that difficult. At Mandrake a diff of the changes (patches 
>>and .spec file) are put into the e-mail announcing the change. This 
>>gives the reader a quick & clear overview of what has changed. For the 
>>sources I would say: let the automated rebuild download them from the 
>>original place, and check the signatures.
>>
>>    
>>
>This isn't secure.  If I, the packager, am trying to crack your
>autobuilder, I can use a
>Source0: http://cracks.com/autorootkit-1.0.tar.gz
>whose "make all" tries to crack the machine.
>A human needs to take at look at the package to filter out active
>attempts to compromise the build machine.
>  
>
Fair. But having a user submit a src.rpm is even worse. It's better to 
let the rebuilding bot download it, eventhough it may be fooled this 
way. At least you can trace back when something went wrong --> better 
audit trails.

Of course, if the source is already in the repository, there is no need 
to get a new copy.

>An even more insidious compromise could be:
>source0: http://www.not-apache-org.com/apache-2.0.48.tar.gz
>which builds a http server with intentional security holes.  One hopes
>that a QA reviewer would see that the package came from a non-canonical
>location but in the case of lesser known software, this kind of Trojan
>could get all the way to an end-user's computer....
>
>Hmmm... Email diffs could be useful when a package was an update of a
>previous package.
>
That's how it's done at Mandrake. I can forward one of their changelog 
e-mails as an example.

>Hopefully, someone would notice that the "canonical"
>Source URL had changed....  Perhaps having the autobuilder not build new
>packages or packages with new Source URLs (hosts?) without having peer
>review done first would be sufficient?
>
My experience is that doing a peer review first is difficult. You won't 
get that many eyeballs, and the eyeballs that should be doing the 
(boring?) job will get tired and let things through.

Better is to:
- make the process as transparent as possible
- have good audit trails in place
- and be able to roll-back a change at any time.

of course, easier said than done.

regards,

Stefan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3403 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.fedoraproject.org/pipermail/devel/attachments/20040108/a6eede4e/attachment-0002.bin