> If this is votable I +1 :-) Make the reviewer do it because they have
> to go through the TODO list anyhow.
+1 from me too, and at worst a 0 from Aurelien, so at the current time
we're in the majority. :)
> > My preference is for the review template to have a series of
> be filled in by the reviewer. A script like qa-assistant could take
> output of our automated program and provide hand-holding for the user
> through filling in the rest of the items.
> > I prefer to have a series of lines like this:
> > Builds OK?: YES (fc1,rh9) NO(rh8)
> > Name OK?: unchecked
> > (Un)Installs OK?: unchecked
> > Secure?: unchecked
> Hmmm... After I define a save format for qa-assistant, I may approach
> you with a --xml-output patch.
XML Output is a great idea IMO. We can define a schema for a review, and
then use xslt to generate the actual review. We should all be able to
easily agree on the xml schema, and for those that love to tweak they
can always change the output template.
In all reality, there may be a certain amount of benefit to actually
posting the review in XML. It's obviously the easiest way of making the
reviews computer parseable.
This may already be what you're doing, I must apologize for not looking
at your code yet :)
> The pointlessness is why I started off by saying a valid GPG signature
> makes checking the MS5sum unnecessary. (ie: only check step 1 above,
> the rest is unnecessary.)
> The more paranoid method I describe checks for inconsistencies between
> the SRPM and other documentation on the SRPM (same person signed both
> files which seem to both refer to the same SRPM. A double check.) In
> the real world, if someone could compromise an SRPM on a server, they
> could probably also compromise the md5sum file.
> This stems from a piece of my original post which you snipped which
> states that I was testing fedora-startqa and it verified the SRPM GPG
> but then errored out because the MD5sum file wasn't up-to-date (and so
> couldn't find the SRPM listed there.) From your comments here, I
> you're planning on removing the md5sum checking so this problem is
> > You still haven't necessarily verified the gpg signature against a
> > of trust, which is FAR more likely to be the source of a problem.
> > 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
> > indicate whether or not the signature that passed was a "trusted"
> > your review accounts gpg keyring.
> Yes, distributing trust is the real tricky problem of gpg.
Cool. Looks like we are on the same page here then. My current
inclination is to require a valid gpg signature, but check md5sums if
possible and note to the user if anything is inconsistent. It certainly
wouldn't hurt to also check that the md5sums they are signed by the same
key as the SRPM, although I doubt many crooks will be caught by it :)
Dave Jones wrote:
I think the issue is...some people on this thread want the the usb mass
storage device to automounted, not just be recognized and added to the
right-click disks menu in nautilus. The want to skip steps 3 and 4 and
go right to step 5.
I was wondering if anyone is developing (b/c the manufacturer are *useless*
about it... you can request for my correspondence w/ them)...
anyways, i was wondering if anyone was developing a promise s150 ata
controller driver? if anything, i'd like to be involved; but i've never
written a driver before. i'm an okay programmer... could anyone point me
to the right direction, please?
I've been using Paul Nasrat's synaptics driver package for some time
without any problems, both with XFree86 and xorg-x11.
This driver is quite essential for many touchpads, so it _would_ be
very nice to include it (starting with test3) in FC2.
+ No matter how much you do, you never do enough -- unknown
+ Whatever you do will be insignificant,
| but it is very important that you do it -- Gandhi
+ So let's do it...?
Please AVOID sending me WORD, EXCEL or POWERPOINT attachments.
i'd like to know if anyone is working on this.
I believe, i read somewhere that the latest suse, as this feature implemented. The icon appear's in the deskop and so.
So i remember to ask. And if no one is working on it, if you guy's think this could be a thing to do. I know there are some programm around, that try to archive this, but not ported to fedora.
If someone as any thing about this, please let me know.
> > - A NEEDSWORK review is just as valuable as a PUBLISH +1 review. I'd
> > like to see the script generate that as well.
> Good idea, right now, the idea is to stop if a QA showstopper is found (no
> signature, build fails in mach), and let the QA'er write the NEEDSWORK
> review. This can be automated a little I think. Added on the TODO list.
My personal opinion is that there shouldn't be a PUBLISH++ in the review template that is automatically output unless we are automatically doing ALL showstopper checks correctly, and the package passes. Currently we can't automate name checking, installation / uninstallation, or complete source checking, so we shouldn't print it out.
Whether or not we should print out "NEEDSWORK++" or something similar is up for debate, probably a good idea.
> > - (Showing my ignorance of mach) How safe is it to build untrusted
> > sources within mach? since mach builds the package before the user gets
> > a chance to go look at whether the Source URL is canonical, I was
> > wondering....
I think I tackled this on in another email. Synopsis: mach is defined as a secure build environment. If it breaks, we need to fix mach. The truly paranoid should do QA under a vserver, UML or even better on a dedicated machine.
> > - Review has "Installs, runs, and uninstalls fine on FC1" but I haven't
> > done any of that yet -- should it be in TODO?
> It is always in the TODO anyway. Erik also thinks that it should not be
> there, so I'll remove it, but I've put it there to remember the user to
> tell which distro he has tested the package on, and to check
> uninstallation. I think that nothing prevents a user from doing a false
> review anyway, and I wanted to make a template where nothing but the
> "notes" had to be added. Anyway, if the majority thinks it's wrong, let's
> remove it.
My preference is for the review template to have a series of "blanks" to be filled in by the reviewer. A script like qa-assistant could take the output of our automated program and provide hand-holding for the user through filling in the rest of the items.
I prefer to have a series of lines like this:
Builds OK?: YES (fc1,rh9) NO(rh8)
Name OK?: unchecked
(Un)Installs OK?: unchecked
The idea here being that the reviewer has a very brief idea of what is required to complete the review beyond what we do automatically, and must sign their name to the fact that they've checked those things when they change "unchecked" to YES.
If they didn't bother to do either, but posted the review anyway, it would still be a useful data point.
> > However, GPG signed SRPMs are equivalent to
> > checking a GPG signed md5sum file that has an md5sum for the SRPM. So
> > my view is if the GPG signature on the SRPM is good and the MD5SUM file
> > doesn't contradict it (ie: different signing keys, different MD5Sums for
> > the same file) it shouldn't error out.
> Yes, there is this -c option to disable srpm md5sum checking.
Agreed. MD5sum's should just be printed out and noted to be checked if they don't exist or mismatch in my opinion. See rant in previous email.
> 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
> reduce that risk. In qa-assistant's checklist, I tried to create a
> of High Security items that should be evaluate before the reviewer
> started doing anything else. Maybe a list like that (minus things
> 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
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
> 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
Thanks for your input!
I have a few items I'd like to mention:
* I suggest the Help sidebar for the firewall setup section of the
anaconda installation procedure (test2+) should contain some notes
explaining the SELinux extension options available. (i.e. Disabled,
Warn, Active). Sure, people should have read the release notes but
adding this keeps with the trend of briefly documenting each section of
the install procedure.
* Within the system-config-network tool, it is now possible to set up
IPSEC VPN links. ( great!) However, the /usr/bin/internet-druid tools
still lists a wizard for setting up CIPE tunnels. Further, it even fails
mentioning that package "cipe" is needed to continue with the setup.
Now, clearly, this is a hold-over of previous OS releases and as such
should be removed from this Internet Config Tool should it not? (esp.
since Red Hat have explained its dropping of the package from the
distribution due to insecurity issues; see recent discussion on the
On that note, would it not be reasonable to replace this CIPE wizard
with the IPSEC one?
* Fedora Core's rhn-applet still associates somewhat with Red Hat's RHN
service now used exclusively with Enterprise products. (Such as
right-click, "RHN Website", etc.) Is it not reasonable to remove any
mention of "RHN" from this applet's configuration screens/options so as
to not mislead/confuse new users into thinking up2date is still
associated with RNH?
- A small side-issue for up2date: Is there any need to continue
inclusion of the "View Advisory" button within up2date screens?
Currently it provides no intended purpose; is there maybe a future
infrastructure being developed to enable a functional button for this?
My apologies if these issues have already been discussed and/or a
mhelios - www.fedoraforum.org
Registered Linux User #348963 / counter.li.org
GnuPG KeyID: 0xCE9F8922 / gnupg.org