fedora-devel-list Digest, Vol 2, Issue 7

Mon Apr 12 12:01:19 UTC 2004

-----Original Message-----
From: fedora-devel-list-bounces at redhat.com
[mailto:fedora-devel-list-bounces at redhat.com] On Behalf Of
fedora-devel-list-request at redhat.com
Sent: Saturday, April 03, 2004 1:35 AM
To: fedora-devel-list at redhat.com
Subject: fedora-devel-list Digest, Vol 2, Issue 7

Send fedora-devel-list mailing list submissions to
	fedora-devel-list at redhat.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.redhat.com/mailman/listinfo/fedora-devel-list
or, via email, send a message with subject or body 'help' to
	fedora-devel-list-request at redhat.com

You can reach the person managing the list at
	fedora-devel-list-owner at redhat.com

When replying, please edit your Subject line so it is more specific than
"Re: Contents of fedora-devel-list digest..."

Today's Topics:

   1. Re: rawhide report: 20040402 changes (Tim Waugh)
   2. RE: fedora-startqa (Erik LaBianca)
   3. RE: RFC: fedora.us QA approval format (Erik LaBianca)
   4. RE: fedora-startqa (Erik LaBianca)
   5. RE: fedora-startqa (seth vidal)
   6. RE: fedora-startqa (Erik LaBianca)
   7. Re: Dependencies not available (Neal D. Becker)
   8. Re: fedora-startqa (Michael Schwendt)
   9. RE: fedora-startqa (Erik LaBianca)
  10. Re: Future: fhs 2.3 compliance for fc3 (Stephen Smoogen)
  11. Re: Future: fhs 2.3 compliance for fc3 (Stephen Smoogen)
  12. Re: Future: fhs 2.3 compliance for fc3 (Stephen Smoogen)
  13. Re: Future: fhs 2.3 compliance for fc3 (Matthew Miller)
  14. Re: Future: fhs 2.3 compliance for fc3 (Jesse Keating)
  15. USB Storage auto-mount. (Nandox7)
  16. Promise ATA and FC1/2 (Paul Rigor)

----------------------------------------------------------------------

Message: 1
Date: Fri, 2 Apr 2004 18:10:41 +0100
From: Tim Waugh <twaugh at redhat.com>
Subject: Re: rawhide report: 20040402 changes
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <20040402171041.GD22468 at redhat.com>
Content-Type: text/plain; charset="us-ascii"

To boot today's boot.iso you'll need to supply 'vdso=0' on the boot line.

Tim.
*/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url :
/archives/fedora-devel-list/attachments/20040402/c98b6f14/attachment.bin

------------------------------

Message: 2
Date: Fri, 2 Apr 2004 12:29:29 -0500
From: "Erik LaBianca" <erik at totalcirculation.com>
Subject: RE: fedora-startqa
To: "Development discussions related to Fedora Core"
	<fedora-devel-list at redhat.com>
Message-ID:
	<4B134FE6AC994B4C99B4D74A8E9EB6590CDABB at smith.interlink.local>
Content-Type: text/plain;	charset="us-ascii"

> 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

------------------------------

Message: 3
Date: Fri, 2 Apr 2004 12:38:51 -0500
From: "Erik LaBianca" <erik at totalcirculation.com>
Subject: RE: RFC: fedora.us QA approval format
To: "Development discussions related to Fedora Core"
	<fedora-devel-list at redhat.com>
Message-ID:
	<4B134FE6AC994B4C99B4D74A8E9EB6590CDABC at smith.interlink.local>
Content-Type: text/plain;	charset="us-ascii"

> > > - Download of the sources, with md5sum check
> >
> > Maybe the download should't be automatic, such that it is possible
to
> check
> > that the download url is really the right url (presumably searching
> first the
> > project home page with google, in order not to use the url provided
in
> the
> > srpm, and verifying that it is the right download page), and not one
> with
> > bad package ?

Re: automatic downloading. My thought is that it's fine to be automatic,
since we print out the url that was downloaded in the TODO section to be
checked manually by the user as they see fit. 

The TODO list is currently eliminated in batch mode, but not for long.

> 
> Reviewers should also notice when upstream projects provide detached
GPG
> signatures, which can be used to verify the published tarballs.
> 

Agreed. I think it's going to have to be left up to the documentation for
now though, since I'm not aware of many standards for how this is done. We
could probably check for SRPMFILENAME.sig or something though, I guess. Any
thoughts?

--erik

------------------------------

Message: 4
Date: Fri, 2 Apr 2004 12:49:22 -0500
From: "Erik LaBianca" <erik at totalcirculation.com>
Subject: RE: fedora-startqa
To: "Development discussions related to Fedora Core"
	<fedora-devel-list at redhat.com>
Message-ID:
	<4B134FE6AC994B4C99B4D74A8E9EB6590CDABD at smith.interlink.local>
Content-Type: text/plain;	charset="iso-8859-1"

> 
> > - 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

------------------------------

Message: 5
Date: Fri, 02 Apr 2004 12:52:01 -0500
From: seth vidal <skvidal at phy.duke.edu>
Subject: RE: fedora-startqa
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <1080928321.16354.27.camel at opus.phy.duke.edu>
Content-Type: text/plain

> 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.
> 

ok, no it's not defined that way.

mach is a program to let you build packages in known-consistent build roots
- it is not secure - someone could have an evil package spec file that can
get out of the chroot and destroy you and your system(and your little dog,
too)

mach+djinni - is much more secure - but not mach by itself.

mach was never intended to be so.

-sv

------------------------------

Message: 6
Date: Fri, 2 Apr 2004 12:59:00 -0500
From: "Erik LaBianca" <erik at totalcirculation.com>
Subject: RE: fedora-startqa
To: "Development discussions related to Fedora Core"
	<fedora-devel-list at redhat.com>
Message-ID:
	<4B134FE6AC994B4C99B4D74A8E9EB6590CDABE at smith.interlink.local>
Content-Type: text/plain;	charset="us-ascii"

> 
> > 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.
> >
> 
> ok, no it's not defined that way.
> 
> mach is a program to let you build packages in known-consistent build 
> roots - it is not secure - someone could have an evil package spec
file
> that can get out of the chroot and destroy you and your system(and
your
> little dog, too)
> 
> mach+djinni - is much more secure - but not mach by itself.
> 
> mach was never intended to be so.
> 

I don't disagree that mach wasn't designed to be secure, but otoh, the
methodology it uses isn't by definition insecure, either.

Well it DOES still chroot. It's not supposed to be easy to break a chroot.
Do you have an example package that breaks it? What is djinni, and why isn't
it included in mach if it makes it secure enough for casual use?

--erik

------------------------------

Message: 7
Date: Fri, 02 Apr 2004 13:07:38 -0500
From: "Neal D. Becker" <ndbecker2 at verizon.net>
Subject: Re: Dependencies not available
To: fedora-devel-list at redhat.com
Message-ID: <c4ka5a$o0f$1 at sea.gmane.org>
Content-Type: text/plain; charset=us-ascii

mgalvin at nycap.rr.com wrote:

> sudo yum update
> Gathering header information file(s) from server(s)
> Server: Fedora Core 1.91 - Development Tree
> Finding updated packages
> Downloading needed headers
> Resolving dependencies
> .Package dvgrab needs libdv.so.2, this is not available. Package pwlib 
> needs libdv.so.2, this is not available. Package xemacs needs 
> libRKC.so.1.2, this is not available. Package xemacs needs 
> libcanna.so.1.2, this is not available. Package ethereal needs 
> libpcap.so.0.8.1, this is not available. Package ethereal-gnome needs 
> libpcap.so.0.8.1, this is not available.
> 
> i get this from all mirrors. are these available somewhere, and if 
> not, when might they be?
> 

Just FYI, I get precisely the same result here.

------------------------------

Message: 8
Date: Fri, 2 Apr 2004 20:10:29 +0200
From: Michael Schwendt <ms-nospam-0306 at arcor.de>
Subject: Re: fedora-startqa
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <20040402201029.6714958d.ms-nospam-0306 at arcor.de>
Content-Type: text/plain; charset=US-ASCII

On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote:

> What is djinni,
> and why isn't it included in mach if it makes it secure enough for 
> casual use?

http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/

------------------------------

Message: 9
Date: Fri, 2 Apr 2004 13:50:19 -0500
From: "Erik LaBianca" <erik at totalcirculation.com>
Subject: RE: fedora-startqa
To: "Development discussions related to Fedora Core"
	<fedora-devel-list at redhat.com>
Message-ID:
	<4B134FE6AC994B4C99B4D74A8E9EB6590CDABF at smith.interlink.local>
Content-Type: text/plain;	charset="us-ascii"

> -----Original Message-----
> From: fedora-devel-list-bounces at redhat.com [mailto:fedora-devel-list- 
> bounces at redhat.com] On Behalf Of Michael Schwendt
> Sent: Friday, April 02, 2004 1:10 PM
> To: Development discussions related to Fedora Core
> Subject: Re: fedora-startqa
> 
> On Fri, 2 Apr 2004 12:59:00 -0500, Erik LaBianca wrote:
> 
> > What is djinni,
> > and why isn't it included in mach if it makes it secure enough for 
> > casual use?
> 
> http://www-user.tu-chemnitz.de/~ensc/fedora.us-build/html/
> 

Ok so now I know what djinni is. And it does nothing to increase the
security of mach. It says "vserver-djinni is used to do privileged tasks
like directory mounting in unprivileged vservers.". 

It is in fact a workaround to using a vserver kernel, which I did note as a
possible security improvement for someone willing to invest the time to
figure it out.

All that being said, to my knowledge vserver consists of a patched chroot
call, a series of capabilities and resource limitations, process tree
separation, and a bunch of tools to facilitate binding to a single network
alias, etc. Most of this stuff is irrelevant to building as an unprivileged
user.

I'd like someone to please demonstrate how building under a chroot running
under a non-privileged user is a true security risk to a development
machine. Moreso than, for instance, exposing an http or ssh daemon. An SRPM
will do fine. Again, the system is supposed to be secure against local root
exploits from unprivileged users to start off with, and running in a chroot
only provides an added level of security. If the mach chroot installs weak
suid binaries, then that's an os-level problem, and for that matter one that
could be fixed pretty easily in mach by removing the suid bit on every file
it installs.

I don't have a problem pointing out to prospective QA'ers that they may get
rooted, but by that line of reasoning we'd better start including those
disclaimers with every copy of bind, sshd, or apache that get shipped with
the OS too. There is an element of risk in everything, and smart security is
all about risk management, not paranoia.

If you're really concerned, there will never be a better option than a
dedicated machine without network access, but how usable is that? We're
trying to REDUCE barriers to entry, aren't we?

--erik

------------------------------

Message: 10
Date: Fri, 2 Apr 2004 12:17:21 -0700 (MST)
From: Stephen Smoogen <smoogen at lanl.gov>
Subject: Re: Future: fhs 2.3 compliance for fc3
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <Pine.LNX.4.58.0404021210220.10176 at smoogen1.lanl.gov>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Thu, 1 Apr 2004, Jeremy Katz wrote:

>On Thu, 2004-04-01 at 15:46 -0700, Stephen Smoogen wrote:
>> The boxes were configured to use the local SMTP for some reason (I 
>> dont know.. I just had to debug the problem). Thus the mail went from 
>> client -> sendmail/var/spool/clientmqueue -> power-outage ooops
>
>Heh, that's just sick.  How about my statement holding for when the 
>clients are set up correctly? :-)  (ie, if you don't use local sendmail 
>and just do smtp, then local /var/spool isn't needed)
>

The counter argument from the guy in suspenders and a beard to his knees 
is that 'when the hell did I get a windows box? Unix is better than 
that.' :). 

>So yes, the ability to have it, perfectly reasonable.  Having it as the 
>general case, perhaps overkill.
>

I think it is reasonable for a completely new environment to not have it 
because you can mandate clients etc. For existing large environments 
where people expect 40 year old editors written in Fortran to still 
work... lets just say exceptions become the rule :(.

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --

------------------------------

Message: 11
Date: Fri, 2 Apr 2004 12:23:16 -0700 (MST)
From: Stephen Smoogen <smoogen at lanl.gov>
Subject: Re: Future: fhs 2.3 compliance for fc3
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <Pine.LNX.4.58.0404021219170.10176 at smoogen1.lanl.gov>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 2 Apr 2004, Havoc Pennington wrote:

>On Thu, 2004-04-01 at 20:52, Chris Adams wrote:
>> Once upon a time, Jeremy Katz <katzj at redhat.com> said:
>> > Heh, that's just sick.  How about my statement holding for when the 
>> > clients are set up correctly? :-)  (ie, if you don't use local 
>> > sendmail and just do smtp, then local /var/spool isn't needed)
>> 
>> Way too many programs expect to be able to call /usr/sbin/sendmail to 
>> assume everything will use SMTP.  And really, that is how it should 
>> be; why should every program be required to have an SMTP client 
>> built-in?
>> 
>> The nice thing about that is that you are pretty much guaranteed that 
>> you can send mail at any time, even if the network is down.  Sendmail 
>> (or another local mailer) will queue the mail locally and send it 
>> when it can.  It is not a good idea to have things like cron jobs get 
>> stuck or lose their output because a remote SMTP server was 
>> unreachable.
>
>I think we have to assume that a managed read-only OS image sort of 
>deployment would have some limitations in possible configurations and 
>what apps could do. After all the whole point is to lock things down.
>
>One setup would be that each user has an outgoing mail queue in their 
>home directory, since homedir already has to be writeable by the user 
>and gets backed up and so forth. Surely you could provide a 
>/usr/sbin/sendmail that worked this way.
>
>A queue in /var is suboptimal because it partially defeats the purpose 
>of the deployment model - it leaves per-machine state to be corrupted, 
>backed up, hacked, etc.
>

How is printing done? How do cron jobs mail when a services home 
directory may not exist and the shell is nologin? Not trying to poke 
holes as much as think things out-loud. I wonder if queues should go 
under /var at all?

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --

------------------------------

Message: 12
Date: Fri, 2 Apr 2004 12:27:31 -0700 (MST)
From: Stephen Smoogen <smoogen at lanl.gov>
Subject: Re: Future: fhs 2.3 compliance for fc3
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <Pine.LNX.4.58.0404021226030.10176 at smoogen1.lanl.gov>
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Fri, 2 Apr 2004, Stephen Smoogen wrote:

>On Fri, 2 Apr 2004, Havoc Pennington wrote:
>
>>A queue in /var is suboptimal because it partially defeats the purpose 
>>of the deployment model - it leaves per-machine state to be corrupted, 
>>backed up, hacked, etc.
>>
>
>How is printing done? How do cron jobs mail when a services home
>directory may not exist and the shell is nologin? Not trying to poke 
>holes as much as think things out-loud. I wonder if queues should go 
>under /var at all?
>

Actually, I think I am needing what the deployment model is and what it 
is for... that would help me get my head around it and what would need 
to be done. I may have a solution to the conundrum, but it needs a 
better idea of what is wanted.

-- 
Stephen John Smoogen		smoogen at lanl.gov
Los Alamos National Lab  CCN-5 Sched 5/40  PH: 4-0645
Ta-03 SM-1498 MailStop B255 DP 10S  Los Alamos, NM 87545
-- You should consider any operational computer to be a security problem --

------------------------------

Message: 13
Date: Fri, 2 Apr 2004 14:40:51 -0500
From: Matthew Miller <mattdm at mattdm.org>
Subject: Re: Future: fhs 2.3 compliance for fc3
To: Development discussions related to Fedora Core
	<fedora-devel-list at redhat.com>
Message-ID: <20040402194051.GA27133 at jadzia.bu.edu>
Content-Type: text/plain; charset=us-ascii

On Thu, Apr 01, 2004 at 12:03:16PM +0200, Nicolas Mailhot wrote:
> Well, let people in the know argue for /media if they want it. So far no
> one here seems to have understood what it's supposed to win over /mnt.

The FHS actually gives the rationalization: having mount points as
subdirectories under /mnt conflicts with an allegedly widespread practice of
using /mnt itself as a temporary mountpoint.

-- 
Matthew Miller           mattdm at mattdm.org        <http://www.mattdm.org/>
Boston University Linux      ------>                <http://linux.bu.edu/>

------------------------------

Message: 14
Date: Fri, 2 Apr 2004 11:41:30 -0800
From: Jesse Keating <jkeating at j2solutions.net>
Subject: Re: Future: fhs 2.3 compliance for fc3
To: fedora-devel-list at redhat.com
Message-ID: <200404021141.30336.jkeating at j2solutions.net>
Content-Type: text/plain; charset="iso-8859-1"

On Friday 02 April 2004 11:40, Matthew Miller wrote:
> The FHS actually gives the rationalization: having mount points as
> subdirectories under /mnt conflicts with an allegedly widespread
> practice of using /mnt itself as a temporary mountpoint.

Alleged.  Thats just it.  I haven't ran across anybody who uses Linux 
that uses /mnt as a mountpoint.  Everybody I've talked to and worked 
with will create their own temp dir under /mnt and mount things there.

-- 
Jesse Keating RHCE      (geek.j2solutions.net)
Fedora Legacy Team      (www.fedoralegacy.org)
GPG Public Key          (geek.j2solutions.net/jkeating.j2solutions.pub)

Was I helpful?  Let others know:
 http://svcs.affero.net/rm.php?r=jkeating
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: signature
Url :
/archives/fedora-devel-list/attachments/20040402/2f4995cb/attachment.bin

------------------------------

Message: 15
Date: Fri, 02 Apr 2004 20:59:48 +0100
From: "Nandox7" <Nandox7 at myrealbox.com>
Subject: USB Storage auto-mount.
To: fedora-devel-list at redhat.com
Message-ID: <1080935988.3e98219cNandox7 at myrealbox.com>
Content-Type: text/plain; charset="UTF-8"

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

------------------------------

Message: 16
Date: Fri, 02 Apr 2004 12:04:44 -0800
From: Paul Rigor <pryce at ucla.edu>
Subject: Promise ATA and FC1/2
To: fedora-devel-list at redhat.com
Message-ID: <6.0.0.22.2.20040402120212.01e43450 at mail.ucla.edu>
Content-Type: text/plain; charset="us-ascii"; format=flowed

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 at ucla.edu
Go Bruins! 

------------------------------

--
fedora-devel-list mailing list
fedora-devel-list at redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

End of fedora-devel-list Digest, Vol 2, Issue 7
***********************************************