Re: [RFC] User Accesable Filesystem Hierarchy Standard
by Jamethiel Knorth
After the previous suggestions on this topic, I have revised the proposed
standard somewhat. It is still posted in a variety of formats at:
http://www.csis.gvsu.edu/~abreschm/uafhs/
I added the suggestion of using .<distribution>/<architecture>/ for a
directory structure, rather than my first change to simply putting it into a
hidden umbrella directory of a standard name. However, I still have several
questions regarding this which I could not find an immediate answer to:
Should there be a standard naming scheme for architectures, or should that
be left completely to the devices of the distribution? I'm tending towards
leaving it to the distribution, but would like some comments.
What about architecture independent systems, like Java? Should each distro
include a 'java' architecture, or something of that sort? There is no
particular reason for such files to be in every architecture's folder when
they work fairly widely.
I also liked the idea of having group directories similar to the shared
directory. In a larger work environment, such directories could solve many
difficult problems. The standard doesn't say much about them, however,
besides that they can be named arbitrarily and should have an internal
structure identical to /home/shared/ and should be located somewhere in
/home/. I don't see what else is needed to be defined on that topic, but
would like any suggestions.
I see no reason to unhide the program folders. They are still perfectly
accessible when they need to be accessed, but they can at least be kept out
of sight. This is even more important when using a naming scheme based on
the distribution which could result in very many folders.
Due to the fact that I merely added to and edited the old document, rather
than going through and actually rewriting it, or at least checking it, the
wording is clunky on several occasions. I'm not too concerned, as this is
still a draft, and will work more on clarity when the ideas to be conveyed
are better decided.
As always, thank you for your commentary and criticism.
Micah Abresch
jamethknorth(a)hotmail.com
P.S. In case anyone was wondering why this was sent to the lists it was:
those are the groups which have easily accessible public lists and to which
this proposed standard seemed relevant.
P.P.S. Many people have contributed ideas in discussions but aren't added to
the contributors section. Luckily, everything is in a public archive so I
can go back and see who suggested what, but it would be easier if anyone who
wanted to be credited would just e-mail me about it.
_________________________________________________________________
Persistent heartburn? Check out Digestive Health & Wellness for information
and advice. http://gerd.msn.com/default.asp
20 years, 1 month
RE: fedora-startqa
by Erik LaBianca
> >
> 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
"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
> > 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 :)
--erik
20 years, 1 month
RE: fedora-startqa
by Erik LaBianca
> >
> The pointlessness is why I started off by saying a valid GPG signature
> makes checking the MS5sum unnecessary. (ie: only check step 1 above,
all
> 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
think
> you're planning on removing the md5sum checking so this problem is
going
> away.
>
> > 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.
> >
> 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 :)
--erik
20 years, 1 month
Re: USB Storage auto-mount.
by Jef Spaleta
Dave Jones wrote:
> http://cyberelk.net/tim/usb-storage.html
>
> Dave
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.
-jef
20 years, 1 month
Promise ATA and FC1/2
by Paul Rigor
Hi all,
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?
cheers,
paul
_________
Paul Rigor
pryce(a)ucla.edu
Go Bruins!
20 years, 1 month
please include the synaptics X11 driver on FC2
by Rui Miguel Silva Seabra
Hi,
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.
Hugs, Rui
--
+ 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.
See http://www.fsf.org/philosophy/no-word-attachments.html
20 years, 1 month
USB Storage auto-mount.
by Nandox7
Hi,
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.
Thank you.
Nando
20 years, 1 month
RE: fedora-startqa
by Erik LaBianca
>
> > - 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
Secure?: 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.
--erik
20 years, 1 month
RE: fedora-startqa
by 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
20 years, 1 month
