-----Original Message----- From: fedora-devel-list-bounces@xxxxxxxxxx [mailto:fedora-devel-list-bounces@xxxxxxxxxx] On Behalf Of fedora-devel-list-request@xxxxxxxxxx Sent: Saturday, April 03, 2004 1:35 AM To: fedora-devel-list@xxxxxxxxxx Subject: fedora-devel-list Digest, Vol 2, Issue 7 Send fedora-devel-list mailing list submissions to fedora-devel-list@xxxxxxxxxx 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@xxxxxxxxxx You can reach the person managing the list at fedora-devel-list-owner@xxxxxxxxxx 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@xxxxxxxxxx> Subject: Re: rawhide report: 20040402 changes To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <20040402171041.GD22468@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" <fedora-devel-list@xxxxxxxxxx> Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABB@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> Subject: RE: RFC: fedora.us QA approval format To: "Development discussions related to Fedora Core" <fedora-devel-list@xxxxxxxxxx> Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABC@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" <fedora-devel-list@xxxxxxxxxx> Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABD@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxx> Subject: RE: fedora-startqa To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <1080928321.16354.27.camel@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" <fedora-devel-list@xxxxxxxxxx> Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABE@xxxxxxxxxxxxxxxxxxxxx> 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@xxxxxxxxxxx> Subject: Re: Dependencies not available To: fedora-devel-list@xxxxxxxxxx Message-ID: <c4ka5a$o0f$1@xxxxxxxxxxxxx> Content-Type: text/plain; charset=us-ascii mgalvin@xxxxxxxxxxxx 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@xxxxxxxx> Subject: Re: fedora-startqa To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <20040402201029.6714958d.ms-nospam-0306@xxxxxxxx> 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@xxxxxxxxxxxxxxxxxxxx> Subject: RE: fedora-startqa To: "Development discussions related to Fedora Core" <fedora-devel-list@xxxxxxxxxx> Message-ID: <4B134FE6AC994B4C99B4D74A8E9EB6590CDABF@xxxxxxxxxxxxxxxxxxxxx> Content-Type: text/plain; charset="us-ascii" > -----Original Message----- > From: fedora-devel-list-bounces@xxxxxxxxxx [mailto:fedora-devel-list- > bounces@xxxxxxxxxx] 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@xxxxxxxx> Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <Pine.LNX.4.58.0404021210220.10176@xxxxxxxxxxxxxxxxx> 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@xxxxxxxx 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@xxxxxxxx> Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <Pine.LNX.4.58.0404021219170.10176@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> 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@xxxxxxxx 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@xxxxxxxx> Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <Pine.LNX.4.58.0404021226030.10176@xxxxxxxxxxxxxxxxx> 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@xxxxxxxx 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@xxxxxxxxxx> Subject: Re: Future: fhs 2.3 compliance for fc3 To: Development discussions related to Fedora Core <fedora-devel-list@xxxxxxxxxx> Message-ID: <20040402194051.GA27133@xxxxxxxxxxxxx> 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@xxxxxxxxxx <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@xxxxxxxxxxxxxxx> Subject: Re: Future: fhs 2.3 compliance for fc3 To: fedora-devel-list@xxxxxxxxxx Message-ID: <200404021141.30336.jkeating@xxxxxxxxxxxxxxx> 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@xxxxxxxxxxxxx> Subject: USB Storage auto-mount. To: fedora-devel-list@xxxxxxxxxx Message-ID: <1080935988.3e98219cNandox7@xxxxxxxxxxxxx> 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@xxxxxxxx> Subject: Promise ATA and FC1/2 To: fedora-devel-list@xxxxxxxxxx Message-ID: <6.0.0.22.2.20040402120212.01e43450@xxxxxxxxxxxxx> 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@xxxxxxxx Go Bruins! ------------------------------ -- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx http://www.redhat.com/mailman/listinfo/fedora-devel-list End of fedora-devel-list Digest, Vol 2, Issue 7 ***********************************************
