fedora-startqa

[Erik LaBianca]

> Two problems:
> 1) In batch mode, the human element is missing.  If it is insecure,
> there needs to be a way to disable mach building from the commandline.
> 
> 2) If the script is aimed at newbies, there should be a warning of the
> potential dangers of building the source package and what can be done
to
> reduce that risk.  In qa-assistant's checklist, I tried to create a
list
> of High Security items that should be evaluate before the reviewer
> started doing anything else.  Maybe a list like that (minus things
that
> are checked automatically) spit out to the screen before viewing the
> spec file?
> 

The whole point of building from within mach is that it IS secure. If it
isn't, it is a bug in the linux chroot system or mach and must be fixed
there. Mach builds are also run as a user, so in order to destroy a
system the SRPM would have to be able to both break a chroot jail and
have a local root exploit applicable to the reviewers currently running
kernel.

In my opinion, we can assume that a build from within mach is secure.
Obviously, you should be doing QA under a dedicated user account as
well.

> I'll give this a try too.  I think, though, what I want is for the
> script to automatically make a decision that an SRPM with a valid GPG
> does not have to have it's md5sum checked.
> 
> Slightly more paranoid is to make the following checks:
> 1] GPG signature of SRPM
> 2] Is the md5sum of the relevant SRPM in the md5sum file?
> 3] GPG signature of md5sum file
> 4] Did the same key sign both files?
> 
> If all pass, then pass the test.
> If 1] Pass and 2] Is fail, pass the test.
> All other cases fail.

I don't see the point in this. All it adds is protection against the
unlikely case that there is a bug in the MD5 checksum code or crypto
routines included in GPG. These tools are designed and tested to be
reliable, second guessing them is a waste of time. If you know enough
about crypto to prove its necessary, I suggest applying that knowledge
to improving those tools.

You still haven't necessarily verified the gpg signature against a web
of trust, which is FAR more likely to be the source of a problem. I'm
not really involved with any of these (webs of trust), but when we
convert the script over to checking RPM sigs using GPG (imminent) we can
indicate whether or not the signature that passed was a "trusted" one in
your review accounts gpg keyring.

In my opinion, the only reason to deal with MD5sums at all is they are
an easy "look at the screen and compare them" method of knowing the
reviewer's reviewed the same SRPM that the author posted. Otherwise, the
author could change the SRPM (but not the filename), resign it, and two
reviewers would end up reviewing different packages and never know it.

MD5Sums obviously provide an easy method of checking download integrity
as well.

Thanks for your input!

--erik