> 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
