From jkeating at redhat.com Wed Mar 1 16:36:22 2006 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 01 Mar 2006 08:36:22 -0800 Subject: Name Poll Message-ID: <1141230982.2563.17.camel@ender> So we weren't able to get the donate for a vote program going for FC5, so instead we've setup a poll for the names that passed through legal. Each of you should get an individual email with a link to cast your vote. Don't share this link as each successive vote replaces the previous one. The poll should be open until 12:00am Monday EST. If you haven't gotten an email within the next few hours, please email me privately (and be honest) and I'll try to arrange for another email to be sent to you or to a different address that will accept the email. Thanks! -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From blizzard at redhat.com Thu Mar 2 13:47:48 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Thu, 02 Mar 2006 08:47:48 -0500 Subject: continuing with sprint development post-fc5 Message-ID: <4406F784.4080400@redhat.com> We've had really good success over the last couple of weeks squashing bugs in a few areas for FC5. This means we've got NetworkManager nearly working in a sane fashion, we've got functional suspend/resume on an ever-growing number of laptops and we've got a good number of cards that support AIGLX. However, due to the time constraints for FC5 and the fact that we want to do some fast paced development post-FC5 to get this functionality working, I suggest that we set up some kind of offically blessed repo, where we can continue refining these important pieces of functionality after FC5 is done, with hopes that they will eventually become official updates. What do people think? Building on a pretty solid FC5 platform would actually make things easier for this kind of development because we don't need to touch great swaths of the operating system. --Chris From orion at cora.nwra.com Thu Mar 2 16:12:24 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 02 Mar 2006 09:12:24 -0700 Subject: continuing with sprint development post-fc5 In-Reply-To: <4406F784.4080400@redhat.com> References: <4406F784.4080400@redhat.com> Message-ID: <44071968.2030702@cora.nwra.com> Christopher Blizzard wrote: > > However, due to the time constraints for FC5 and the fact that we want > to do some fast paced development post-FC5 to get this functionality > working, I suggest that we set up some kind of offically blessed repo, > where we can continue refining these important pieces of functionality > after FC5 is done, with hopes that they will eventually become official > updates. While I'm not tracking this development, I think having various development repos tracking various SIGs and the like would be very useful. Coupled with a Extras like build system it might make for a great development hotbed. People could submit packages for building and have them available for everyone else minutes later. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From jspaleta at gmail.com Thu Mar 2 16:25:47 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 2 Mar 2006 11:25:47 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <4406F784.4080400@redhat.com> References: <4406F784.4080400@redhat.com> Message-ID: <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> On 3/2/06, Christopher Blizzard wrote: > However, due to the time constraints for FC5 and the fact that we want > to do some fast paced development post-FC5 to get this functionality > working, I suggest that we set up some kind of offically blessed repo, > where we can continue refining these important pieces of functionality > after FC5 is done, with hopes that they will eventually become official > updates. Uhm... isn't the per Core release updates-testing repo appropriate for exactly this sort of work? -jef From fedora at leemhuis.info Thu Mar 2 17:11:02 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 02 Mar 2006 18:11:02 +0100 Subject: continuing with sprint development post-fc5 In-Reply-To: <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> Message-ID: <1141319462.2319.15.camel@localhost.localdomain> Am Donnerstag, den 02.03.2006, 11:25 -0500 schrieb Jeff Spaleta: > On 3/2/06, Christopher Blizzard wrote: > > However, due to the time constraints for FC5 and the fact that we want > > to do some fast paced development post-FC5 to get this functionality > > working, I suggest that we set up some kind of offically blessed repo, > > where we can continue refining these important pieces of functionality > > after FC5 is done, with hopes that they will eventually become official > > updates. Great idea. > Uhm... isn't the per Core release updates-testing repo appropriate for > exactly this sort of work? I considered the same answer. But the more I think about it the more I tend to "no, that's not a good idea". We might scare away those that only want to help testing updated packages that *should* work fine before they enter updates proper. So my vote: Create updates-experimental for this stuff. CU thl -- Thorsten Leemhuis From nicolas.mailhot at laposte.net Thu Mar 2 18:20:57 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 02 Mar 2006 19:20:57 +0100 Subject: continuing with sprint development post-fc5 In-Reply-To: <1141319462.2319.15.camel@localhost.localdomain> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> Message-ID: <1141323657.21012.10.camel@rousalka.dyndns.org> Le jeudi 02 mars 2006 ? 18:11 +0100, Thorsten Leemhuis a ?crit : > > Uhm... isn't the per Core release updates-testing repo appropriate for > > exactly this sort of work? > > I considered the same answer. But the more I think about it the more I > tend to "no, that's not a good idea". We might scare away those that > only want to help testing updated packages that *should* work fine > before they enter updates proper. > > So my vote: Create updates-experimental for this stuff. I'm pretty sure you do NOT want to create such a repository. If you create a single repository, where davej will push kernels, mharris xorg updates, dan selinux stuff etc : 1. you're recreating rawhide (badly, by another name). What one maintainer will call an acceptable experiment another will call destabilising the common repo 2. you have the same problem as before : users are scared because they may agree to experiment with the kernel, or selinux, or xorg, or something_else, but never all of them at once What you need is something like what happens on p.r.c., or with kernel trees : specialized repos, each with a clearly defined functional target, and only the stuff related to this target. If you do it this way it'll be a big success. If you mix everything it will be a repo in search of users like updates-testing. (also if you separate stuff you can always create a consolidated repo too, but I doubt it'll be used) Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From jwboyer at jdub.homelinux.org Thu Mar 2 18:36:49 2006 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 2 Mar 2006 12:36:49 -0600 (CST) Subject: continuing with sprint development post-fc5 In-Reply-To: <1141323657.21012.10.camel@rousalka.dyndns.org> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> Message-ID: <17573.129.42.161.36.1141324609.squirrel@jdub.homelinux.org> > Le jeudi 02 mars 2006 ? 18:11 +0100, Thorsten Leemhuis a ??crit : > >> > Uhm... isn't the per Core release updates-testing repo appropriate for >> > exactly this sort of work? >> >> I considered the same answer. But the more I think about it the more I >> tend to "no, that's not a good idea". We might scare away those that >> only want to help testing updated packages that *should* work fine >> before they enter updates proper. >> >> So my vote: Create updates-experimental for this stuff. > > I'm pretty sure you do NOT want to create such a repository. > If you create a single repository, where davej will push kernels, > mharris xorg updates, dan selinux stuff etc : > 1. you're recreating rawhide (badly, by another name). What one > maintainer will call an acceptable experiment another will call > destabilising the common repo > 2. you have the same problem as before : users are scared because they > may agree to experiment with the kernel, or selinux, or xorg, or > something_else, but never all of them at once I see your point, but at the same time some of the stuff Chris is talking about involves all of those things. Like suspend... it's more than just the kernel needed. > What you need is something like what happens on p.r.c., or with kernel > trees : specialized repos, each with a clearly defined functional > target, and only the stuff related to this target. Which can be the kernel, selinux, xorg, _and_ something_else depending on the target :). > > If you do it this way it'll be a big success. If you mix everything it > will be a repo in search of users like updates-testing. It'll also be a big PITA. That could be a lot of repos depending on how things fall out. I think the bigger question is, are the Core developers going to have time to do this? If not, then it's largely a waste of time. I'm cautiously optimistic :) josh From bressers at redhat.com Thu Mar 2 20:47:56 2006 From: bressers at redhat.com (Josh Bressers) Date: Thu, 02 Mar 2006 15:47:56 -0500 Subject: Announcing fedora-security-list Message-ID: <200603022047.k22KluSb013054@devserv.devel.redhat.com> There has been a fair amount of talk regarding how to handle security updates in Fedora Extras. Current handling of these updates is up to the package maintainer. The fedora-security-list has been created for just such discussions, with the hope of the community to devise a solution to deal with Extras security issues. The scope of this list is not limited to Extras security, but rather a list with a focus on security issues in Fedora along with how the various security groups can work together. You can subscribe to the list here: https://www.redhat.com/mailman/listinfo/fedora-security-list Thanks, Josh -- Josh Bressers // Red Hat Security Response Team From mharris at mharris.ca Fri Mar 3 00:41:17 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 02 Mar 2006 19:41:17 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <1141323657.21012.10.camel@rousalka.dyndns.org> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> Message-ID: <440790AD.2060106@mharris.ca> Nicolas Mailhot wrote: > Le jeudi 02 mars 2006 ? 18:11 +0100, Thorsten Leemhuis a ?crit : > > >>>Uhm... isn't the per Core release updates-testing repo appropriate for >>>exactly this sort of work? >> >>I considered the same answer. But the more I think about it the more I >>tend to "no, that's not a good idea". We might scare away those that >>only want to help testing updated packages that *should* work fine >>before they enter updates proper. >> >>So my vote: Create updates-experimental for this stuff. > > > I'm pretty sure you do NOT want to create such a repository. > If you create a single repository, where davej will push kernels, > mharris xorg updates, dan selinux stuff etc : > 1. you're recreating rawhide (badly, by another name). What one > maintainer will call an acceptable experiment another will call > destabilising the common repo > 2. you have the same problem as before : users are scared because they > may agree to experiment with the kernel, or selinux, or xorg, or > something_else, but never all of them at once > > What you need is something like what happens on p.r.c., or with kernel > trees : specialized repos, each with a clearly defined functional > target, and only the stuff related to this target. > > If you do it this way it'll be a big success. If you mix everything it > will be a repo in search of users like updates-testing. > > (also if you separate stuff you can always create a consolidated repo > too, but I doubt it'll be used) I strongly agree with this view. Someone may want to be a guinea pig for aiglx et al. but not want to mess around with experimental kernels, openoffice or other components. It makes the most sense to have a separate repo per development domain, where a domain is a single package, group of packages, or group of packages including special dependencies they need, etc. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From fedora at leemhuis.info Fri Mar 3 06:19:42 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 03 Mar 2006 07:19:42 +0100 Subject: continuing with sprint development post-fc5 In-Reply-To: <440790AD.2060106@mharris.ca> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> Message-ID: <1141366782.29413.25.camel@thl.ct.heise.de> Am Donnerstag, den 02.03.2006, 19:41 -0500 schrieb Mike A. Harris: > Nicolas Mailhot wrote: > > Le jeudi 02 mars 2006 ? 18:11 +0100, Thorsten Leemhuis a ?crit : > >>>Uhm... isn't the per Core release updates-testing repo appropriate for > >>>exactly this sort of work? > >>I considered the same answer. But the more I think about it the more I > >>tend to "no, that's not a good idea". We might scare away those that > >>only want to help testing updated packages that *should* work fine > >>before they enter updates proper. > >>So my vote: Create updates-experimental for this stuff. > > I'm pretty sure you do NOT want to create such a repository. > > If you create a single repository, where davej will push kernels, > > mharris xorg updates, dan selinux stuff etc : > > 1. you're recreating rawhide (badly, by another name). What one > > maintainer will call an acceptable experiment another will call > > destabilising the common repo I disagree a small bit. Rawhide would probably be way more experimental (depends on how exactly such a repo was filled). For example it is to experimental for me and needs to much internet-bandwidth for the updates. But I would use such a experimental repo. > > 2. you have the same problem as before : users are scared because they > > may agree to experiment with the kernel, or selinux, or xorg, or > > something_else, but never all of them at once You can put "exclude=foo" or "include=foo" into your yum config if you don't want everything. Site note so skvidal: Maybe a "includewithdeps=foo" would be nice enhancement for .repo files. E.g. include foo, but if it needs bar from the same repo include that, too. > > What you need is something like what happens on p.r.c., or with kernel > > trees : specialized repos, each with a clearly defined functional > > target, and only the stuff related to this target. And is hard to manage and to find. Each maintainer uses a different layout. yum repodata was often missing, too. And space it limited on p.r.c iirc. And there is no documentation or summary where to find what. > > If you do it this way it'll be a big success. If you mix everything it > > will be a repo in search of users like updates-testing. > > > > (also if you separate stuff you can always create a consolidated repo > > too, but I doubt it'll be used) I would use it. > I strongly agree with this view. Someone may want to be a guinea pig > for aiglx et al. but not want to mess around with experimental kernels, > openoffice or other components. It makes the most sense to have a > separate repo per development domain, where a domain is a single > package, group of packages, or group of packages including special > dependencies they need, etc. Well, than let do this: Create somewhere a place where all experimental update stuff is collected in separate repos (site by site, same layout, with yum repodata, so people actually can find it easily and don't have to search p.r.c over and over). Create a Meta-Repo where all those files from the other repos are included. Best of both worlds. CU thl From sundaram at fedoraproject.org Fri Mar 3 19:00:24 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 00:30:24 +0530 Subject: continuing with sprint development post-fc5 In-Reply-To: <1141366782.29413.25.camel@thl.ct.heise.de> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> Message-ID: <44089248.1010706@fedoraproject.org> Thorsten Leemhuis wrote: >You can put "exclude=foo" or "include=foo" into your yum config if you >don't want everything. > >Site note so skvidal: Maybe a "includewithdeps=foo" would be nice >enhancement for .repo files. E.g. include foo, but if it needs bar from >the same repo include that, too. > Such a option would be extremely useful for testers. Why not change the behavior of exclude option to exclude the related dependencies automatically? -- Rahul From nicolas.mailhot at laposte.net Fri Mar 3 19:13:11 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 03 Mar 2006 20:13:11 +0100 Subject: continuing with sprint development post-fc5 In-Reply-To: <44089248.1010706@fedoraproject.org> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> Message-ID: <1141413191.22501.2.camel@rousalka.dyndns.org> > Thorsten Leemhuis wrote: > > >You can put "exclude=foo" or "include=foo" into your yum config if you > >don't want everything. Do you want a rawhide user opinion on exclude tricks ? Really ? Repo creators know what packages belong together. Users don't and emphatically do NOT want to learn it -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From skvidal at linux.duke.edu Fri Mar 3 19:19:18 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 03 Mar 2006 14:19:18 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <44089248.1010706@fedoraproject.org> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> Message-ID: <1141413558.4694.24.camel@cutter> On Sat, 2006-03-04 at 00:30 +0530, Rahul Sundaram wrote: > Thorsten Leemhuis wrote: > > >You can put "exclude=foo" or "include=foo" into your yum config if you > >don't want everything. > > > >Site note so skvidal: Maybe a "includewithdeps=foo" would be nice > >enhancement for .repo files. E.g. include foo, but if it needs bar from > >the same repo include that, too. > > > Such a option would be extremely useful for testers. Why not change the > behavior of exclude option to exclude the related dependencies > automatically? b/c the deps may not only be deps of what you excluded. moreover it's putting waaay too much thinking into the depsolver. the user needs to think more. -sv From sundaram at fedoraproject.org Sat Mar 4 00:51:31 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 06:21:31 +0530 Subject: Wild cry for package documentation Message-ID: <4408E493.9040101@fedoraproject.org> Hi I send out a note to https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html to document packages in Fedora Extras is a better way when the installation or configuration procedures are non obvious and we are seeing changes such as the Games Special Interest Group (http://fedoraproject.org/wiki/Extras/SIGs/Games) tackling https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html . I would like to see that happen for Fedora Core packages too. Use the fedora wiki whenever you can. We can publish them formally in Fedora if required. http://fedoraproject.org/wiki/DocsProject On a related note all the RHEL documentation is being relicensed to OPL to match the new Fedora documentation licensing requirement and thereby pushing in tons of nice documentation available soon for Fedora not to mention less duplication of work. http://www.redhat.com/archives/fedora-docs-list/2006-February/msg00110.html -- Rahul From fedora at soeterbroek.com Sat Mar 4 08:16:14 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Sat, 04 Mar 2006 09:16:14 +0100 Subject: Wild cry for package documentation In-Reply-To: <4408E493.9040101@fedoraproject.org> References: <4408E493.9040101@fedoraproject.org> Message-ID: <1141460174.3444.4.camel@alexandria> On Sat, 2006-03-04 at 06:21 +0530, Rahul Sundaram wrote: > Hi > > I send out a note to > https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html > to document packages in Fedora Extras is a better way when the > installation or configuration procedures are non obvious and we are > seeing changes such as the Games Special Interest Group > (http://fedoraproject.org/wiki/Extras/SIGs/Games) tackling > https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html > . I would like to see that happen for Fedora Core packages too. Use the > fedora wiki whenever you can. We can publish them formally in Fedora if > required. Is there an example page, category page and/or page template that I can use. I like the idea of a package page and would like to make one for the packages I maintain. Joost From fedora at soeterbroek.com Sat Mar 4 10:23:04 2006 From: fedora at soeterbroek.com (Joost Soeterbroek) Date: Sat, 04 Mar 2006 11:23:04 +0100 Subject: Wild cry for package documentation In-Reply-To: <4408E493.9040101@fedoraproject.org> References: <4408E493.9040101@fedoraproject.org> Message-ID: <1141467784.3444.8.camel@alexandria> On Sat, 2006-03-04 at 06:21 +0530, Rahul Sundaram wrote: > Hi > > I send out a note to > https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html > to document packages in Fedora Extras is a better way when the > installation or configuration procedures are non obvious and we are > seeing changes such as the Games Special Interest Group > (http://fedoraproject.org/wiki/Extras/SIGs/Games) tackling > https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html > . I would like to see that happen for Fedora Core packages too. Use the > fedora wiki whenever you can. We can publish them formally in Fedora if > required. How about this as a start: http://fedoraproject.org/wiki/heartbeat http://fedoraproject.org/wiki/trac Any Comments, remarks? Joost From sundaram at fedoraproject.org Sat Mar 4 12:30:08 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 18:00:08 +0530 Subject: Wild cry for package documentation In-Reply-To: <1141460174.3444.4.camel@alexandria> References: <4408E493.9040101@fedoraproject.org> <1141460174.3444.4.camel@alexandria> Message-ID: <44098850.60507@fedoraproject.org> Joost Soeterbroek wrote: >On Sat, 2006-03-04 at 06:21 +0530, Rahul Sundaram wrote: > > >>Hi >> >>I send out a note to >>https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html >>to document packages in Fedora Extras is a better way when the >>installation or configuration procedures are non obvious and we are >>seeing changes such as the Games Special Interest Group >>(http://fedoraproject.org/wiki/Extras/SIGs/Games) tackling >>https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html >>. I would like to see that happen for Fedora Core packages too. Use the >>fedora wiki whenever you can. We can publish them formally in Fedora if >>required. >> >> > >Is there an example page, category page and/or page template that I can >use. I like the idea of a package page and would like to make one for >the packages I maintain. > > The links in http://www.fedoraproject.org/wiki/Games are examples of the work being currently done. -- Rahul From sundaram at fedoraproject.org Sat Mar 4 12:31:11 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Sat, 04 Mar 2006 18:01:11 +0530 Subject: Wild cry for package documentation In-Reply-To: <1141467784.3444.8.camel@alexandria> References: <4408E493.9040101@fedoraproject.org> <1141467784.3444.8.camel@alexandria> Message-ID: <4409888F.70805@fedoraproject.org> Joost Soeterbroek wrote: >On Sat, 2006-03-04 at 06:21 +0530, Rahul Sundaram wrote: > > >>Hi >> >>I send out a note to >>https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html >>to document packages in Fedora Extras is a better way when the >>installation or configuration procedures are non obvious and we are >>seeing changes such as the Games Special Interest Group >>(http://fedoraproject.org/wiki/Extras/SIGs/Games) tackling >>https://www.redhat.com/archives/fedora-extras-list/2006-March/msg00120.html >>. I would like to see that happen for Fedora Core packages too. Use the >>fedora wiki whenever you can. We can publish them formally in Fedora if >>required. >> >> > >How about this as a start: > http://fedoraproject.org/wiki/heartbeat > http://fedoraproject.org/wiki/trac > > > That looks good. Other wants them in http://fedoraproject.org/wiki/Packages/ namespace. CategoriesPackages is important for all those packages. -- Rahul From fedora at leemhuis.info Sat Mar 4 12:45:12 2006 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 04 Mar 2006 13:45:12 +0100 Subject: Rebuild status Message-ID: <1141476312.8209.35.camel@localhost.localdomain> Hi all, latest rebuild status: 181 Packages still need a rebuild. Site note: Guys, hurry up! We only have round about one and a halve week until FC5 is shipped. Most packages should e rebuild by then or we should at least know why they are not yet rebuild. We should also try to get all missing deps fixed until then! For some packages there are excuses know why they are not yet rebuild or don't need a rebuild. See the wiki page http://www.fedoraproject.org/wiki/Extras/FC5Status for details. Please add comments there for all packages that are not yet rebuild. aaron.bennett_AT_olin.edu ifplugd 0.24-6 ad+rh-bugzilla_AT_uni-x.org pam_abl 0.2.2-2.fc5 adrian_AT_lisas.de kover 2.9.6-4 adrian_AT_lisas.de libcdio 0.76-1.fc5 adrian_AT_lisas.de most 4.10.2-2.fc5 adrian_AT_lisas.de nexuiz 1.2.1-3.fc5 adrian_AT_lisas.de ninja 1.5.8.1-2 adrian_AT_lisas.de sopwith 1.7.1-2 adrian_AT_lisas.de source-highlight 2.2-1.fc5 adrian_AT_lisas.de tin 1.6.2-4 adrian_AT_lisas.de uudeview 0.5.20-4 adrian_AT_lisas.de vnstat 1.4-5 adrian_AT_lisas.de xdesktopwaves 1.3-4 anvil_AT_livna.org aalib 1.4.0-0.rc5.7 anvil_AT_livna.org bin2iso 1.9-2.b anvil_AT_livna.org imlib2 1.2.1-5.fc5 anvil_AT_livna.org irssi 0.8.10-3.fc5 anvil_AT_livna.org libcddb 1.2.1-1.fc5 anvil_AT_livna.org libebml 0.7.6-1.fc5 anvil_AT_livna.org libmatroska 0.8.0-1.fc5 anvil_AT_livna.org libsamplerate 0.1.2-3.fc4 anvil_AT_livna.org libsndfile 1.0.11-3.fc4 anvil_AT_livna.org libtar 1.2.11-5 anvil_AT_livna.org lzo 1.08-5.fc5 aportal_AT_univ-montp2.fr gpsim 0.21.11-1.fc5 aportal_AT_univ-montp2.fr gputils 0.13.3-1.fc5 aportal_AT_univ-montp2.fr gtk+extra 2.1.1-1.fc5 bdpepple_AT_ameritech.net gnomebaker 0.5.1-2.fc5 bugs.michael_AT_gmx.net aide 0.10-2 byte_AT_fedoraproject.org adns 1.1-5 byte_AT_fedoraproject.org gaim-guifications 2.12-2.fc5 byte_AT_fedoraproject.org MagicPoint 1.11b-2.fc5 byte_AT_fedoraproject.org python-adns 1.1.0-1 chrisw_AT_redhat.com git-core 0.99.9a-2.fc5 davidhart_AT_tqmcube.com leafnode 1.9.53-3 davidz_AT_redhat.com NetworkManager-vpnc 0.5.0-1 dwmw2_AT_redhat.com exim 4.60-2.fc5 dwmw2_AT_redhat.com hfsplusutils 1.0.4-5 endur_AT_bennewitz.com streamtuner 0.99.99-11.fc5 enrico.scholz_AT_informatik.tu-chemnitz.de libtasn1 0.2.6-3 enrico.scholz_AT_informatik.tu-chemnitz.de util-vserver 0.30.210-1.fc5 extras-orphan_AT_fedoraproject.org abe 1.0-5 extras-orphan_AT_fedoraproject.org at-poke 0.2.2-2 extras-orphan_AT_fedoraproject.org dia 0.94-19 extras-orphan_AT_fedoraproject.org duplicity 0.4.1-4 extras-orphan_AT_fedoraproject.org gnofract4d 2.6-3 extras-orphan_AT_fedoraproject.org lua 5.0.2-5.fc5 extras-orphan_AT_fedoraproject.org ots 0.4.2-7 extras-orphan_AT_fedoraproject.org wbxml2 0.9.0-4 fedora_AT_soeterbroek.com xmms-cdread 0.14-6.a fredrik_AT_dolda2000.com icmpdn 0.3-2 gemi_AT_bluewin.ch audacity 1.2.3-5 gemi_AT_bluewin.ch bigloo 2.7a-2.fc5 gemi_AT_bluewin.ch erlang R10B-8.3.fc5 gemi_AT_bluewin.ch TeXmacs 1.0.5.12-2.fc5 ghenry_AT_suretecsystems.com john 1.6-4 green_AT_redhat.com jogl 1.1.1-13.fc5 green_AT_redhat.com kawa 1.8-3.fc5 green_AT_redhat.com rssowl 1.2-10.fc5 ivazquez_AT_ivazquez.net lock-keys-applet 1.0-9 jcarpenter_AT_condell.org ks3switch 0.1-1.fc5 jcarpenter_AT_condell.org lrmi 0.9-2.fc5 jcarpenter_AT_condell.org s3switch 0.0-6.20020912 jcarpenter_AT_condell.org tpb 0.6.4-2.fc5 jcarpenter_AT_condell.org xosd 2.2.14-4.fc5 jeff_AT_ultimateevil.org up-imapproxy 1.2.4-4.fc5 jeff_AT_ultimateevil.org zile 2.2.4-2.fc5 jnovy_AT_redhat.com cproto 4.7d-2 jnovy_AT_redhat.com nedit 5.5-6 joost_AT_cnoc.nl fpc 2.0.2-3.fc5 jpo_AT_di.uminho.pt libol 0.3.16-2.fc5 jpo_AT_di.uminho.pt perl-DBD-SQLite 1.11-1.fc5 jylitalo_AT_iki.fi python-imaging 1.1.4-9 lemenkov_AT_newmail.ru chmlib 0.37.4-4.fc5 lemenkov_AT_newmail.ru fuse-encfs 1.2.5-1.fc5 lemenkov_AT_newmail.ru rlog 1.3.7-1.fc5 lemenkov_AT_newmail.ru wavpack 4.31-1.fc5 llch_AT_redhat.com libtabe 0.2.6-14 llch_AT_redhat.com xcin 2.5.3.pre3-27 mattdm_AT_mattdm.org wxPythonGTK2 2.4.2.4-7 matthias_AT_rpmforge.net advancecomp 1.15-3.fc5 matthias_AT_rpmforge.net bbkeys 0.9.0-3.fc5 matthias_AT_rpmforge.net blackbox 0.70.1-3.fc5 matthias_AT_rpmforge.net boa 0.94.14-0.3.rc21.fc5 matthias_AT_rpmforge.net camE 1.9-5.fc5 matthias_AT_rpmforge.net csmash 0.6.6-11.fc5 matthias_AT_rpmforge.net d4x 2.5.6-1.fc5 matthias_AT_rpmforge.net diradmin 1.7.1-3.fc5 matthias_AT_rpmforge.net djvulibre 3.5.15-2.fc5 matthias_AT_rpmforge.net easytag 1.1-2.fc5 matthias_AT_rpmforge.net fillets-ng 0.7.3-2.fc5 matthias_AT_rpmforge.net gcombust 0.1.55-7 matthias_AT_rpmforge.net gentoo 0.11.55-2.fc5 matthias_AT_rpmforge.net giblib 1.2.4-5.fc5 matthias_AT_rpmforge.net gkrellm-aclock 0.3.3-3.fc5 matthias_AT_rpmforge.net gkrellm-freq 1.0-1.fc5 matthias_AT_rpmforge.net Gtk-Perl 0.7008-39.fc5 matthias_AT_rpmforge.net gtktalog 1.0.4-6.fc5 matthias_AT_rpmforge.net gtweakui 0.4.0-1.fc5 matthias_AT_rpmforge.net hackedbox 0.8.4-5.fc5 matthias_AT_rpmforge.net hercules 3.02-3 matthias_AT_rpmforge.net i8kutils 1.25-5.fc5 matthias_AT_rpmforge.net js 1.5-3.fc5 matthias_AT_rpmforge.net kannel 1.4.0-7.fc5 matthias_AT_rpmforge.net libcaca 0.9-9.fc5 matthias_AT_rpmforge.net liboil 0.3.6-1.fc5 matthias_AT_rpmforge.net lighttpd 1.4.10-1.fc5 matthias_AT_rpmforge.net linux_logo 4.13-1.fc5 matthias_AT_rpmforge.net lmarbles 1.0.7-4 matthias_AT_rpmforge.net metakit 2.4.9.5-1.fc5 matthias_AT_rpmforge.net ncftp 3.1.9-2.fc5 matthias_AT_rpmforge.net oidentd 2.0.7-8.fc5 matthias_AT_rpmforge.net p7zip 4.30-2.fc5 matthias_AT_rpmforge.net php-eaccelerator 5.0.4_0.9.3-3.fc5 matthias_AT_rpmforge.net php-pecl-mailparse 2.1.1-2.fc5 matthias_AT_rpmforge.net php-pecl-pdo 1.0.2-1.fc5 matthias_AT_rpmforge.net php-pecl-pdo-sqlite 0.3-3.fc5 matthias_AT_rpmforge.net plib16 1.6.0-4.fc5 matthias_AT_rpmforge.net plib 1.8.4-2.fc5 matthias_AT_rpmforge.net portaudio 18.1-6.fc5 matthias_AT_rpmforge.net powermanga 0.79-7.fc5 matthias_AT_rpmforge.net proftpd 1.3.0-0.1.rc3.fc5 matthias_AT_rpmforge.net rrdtool 1.0.49-5.fc4 matthias_AT_rpmforge.net SDL_gfx 2.0.13-3.fc5 matthias_AT_rpmforge.net starfighter 1.1-6.fc5 matthias_AT_rpmforge.net synergy 1.2.7-1.fc5 matthias_AT_rpmforge.net thttpd 2.25b-9.fc5 matthias_AT_rpmforge.net torcs 1.2.4-1.fc5 matthias_AT_rpmforge.net ucarp 1.1-4.fc5 matthias_AT_rpmforge.net udftools 1.0.0b3-4.fc5 matthias_AT_rpmforge.net viruskiller 0.9-6.fc5 matthias_AT_rpmforge.net xvattr 1.3-8.fc5 matthias_AT_rpmforge.net yasm 0.4.0-5.fc5 matthias_AT_rpmforge.net zziplib 0.13.45-1.fc5 mccann0011_AT_hotmail.com geos 2.2.1-3.fc5 mccann0011_AT_hotmail.com proj 4.4.9-1.fc5 michel.salim_AT_gmail.com gai-pal 0.7-7 mihai_AT_xcyb.org htb-util 0.2.4-0.4.pre1 nhorman_AT_redhat.com iozone 3-1 oliver_AT_linux-kernel.at fish 1.12.0-1.fc5 oliver_AT_linux-kernel.at libdnet 1.10-2.fc5 otaylor_AT_redhat.com libuninameslist 0.0-4.040707 petersen_AT_redhat.com darcs 1.0.5-1.fc5 petersen_AT_redhat.com ghc 6.4.1-2.fc5 petersen_AT_redhat.com haddock 0.7-1.fc5 rdieter_AT_math.unl.edu factory 2.0.5-6 rdieter_AT_math.unl.edu gsview 4.7-5.fc5.1 rdieter_AT_math.unl.edu libfac 2.0.5-3 rdieter_AT_math.unl.edu lyx 1.3.6-3.fc5 rdieter_AT_math.unl.edu Macaulay2 0.9.2-17.fc4 redhat_AT_flyn.org pam_mount 0.9.25-4 steve_AT_silug.org tuxpaint 0.9.13-3 tagoh_AT_redhat.com Canna 3.7p3-14.fc5 tagoh_AT_redhat.com kinput2 v3.1-26.fc5 tcallawa_AT_redhat.com compat-wxGTK 2.4.2-16.fc5 tcallawa_AT_redhat.com libgdamm 1.3.7-2.fc5 tcallawa_AT_redhat.com logjam 4.5.1-5.fc5 tcallawa_AT_redhat.com R 2.2.1-3.fc5 tcallawa_AT_redhat.com R-gnomeGUI 2.1.0-4 tcallawa_AT_redhat.com scalapack 1.7-7.fc4 tcallawa_AT_redhat.com xbase 2.0.0-3.fc5 tcallawa_AT_redhat.com xbsql 0.11-5.fc5 thomas_AT_apestaart.org directfb 0.9.24-4.fc5 thomas_AT_apestaart.org flumotion 0.1.8-1 thomas_AT_apestaart.org gstreamer08-python 0.8.3-1.fc5 thomas_AT_apestaart.org gstreamer-python 0.10.2-1.fc5 thomas_AT_apestaart.org Hermes 1.3.3-7 thomas_AT_apestaart.org ladspa 1.12-5 thomas_AT_apestaart.org libannodex 0.7.2-1.fc5 thomas_AT_apestaart.org libcmml 0.9.0-2.fc5 thomas_AT_apestaart.org liboggz 0.9.3-2.fc5 thomas_AT_apestaart.org libshout 1.0.9-4 thomas_AT_apestaart.org mach 0.4.8-1.fc5 thomas_AT_apestaart.org mod_annodex 0.2.2-2.fc5 thomas_AT_apestaart.org python-twisted 1.3.0-4 toniw_AT_iki.fi silky 0.5.4-1 tripwire-devel_AT_genesis-x.nildram.co.uk tripwire 2.3.1-22 wtogami_AT_redhat.com bonnie++ 1.03a-4 wtogami_AT_redhat.com lvcool 1.0.0-3 wtogami_AT_redhat.com perl-Digest-Nilsimsa 0.06-5 wtogami_AT_redhat.com perl-Razor-Agent 2.77-2.fc5 -- Thorsten Leemhuis From pertusus at free.fr Sat Mar 4 12:48:26 2006 From: pertusus at free.fr (Patrice Dumas) Date: Sat, 4 Mar 2006 13:48:26 +0100 Subject: Wild cry for package documentation In-Reply-To: <1141467784.3444.8.camel@alexandria> References: <4408E493.9040101@fedoraproject.org> <1141467784.3444.8.camel@alexandria> Message-ID: <20060304124826.GA3005@free.fr> > http://fedoraproject.org/wiki/trac I'm not persuaded that the Installation instruction part is needed, otherwise it seems good. For heartbeat, I think that the installation instructions are usefull because there are the optionnal sub-packages. -- Pat From ville.skytta at iki.fi Mon Mar 6 07:53:58 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Mon, 06 Mar 2006 09:53:58 +0200 Subject: Incoming: pcsc-lite FE5 soname change Message-ID: <1141631638.8360.14.camel@bobcat.mine.nu> Just a heads up, I'm going to update pcsc-lite in FE5 (only) to version 1.3.0, which includes a libpcsclite.so.0 -> libpcsclite.so.1 soname change. I'm the maintainer of all packages in Extras that have a hard dependency on pcsc-lite-libs and will take care of the rebuilds. gnupg2 also has a "soft" dependency on it, will submit a patch. (Sorry for the crosspost, I don't remember what, if anything, has been agreed about where messages like this should be sent.) From blizzard at redhat.com Mon Mar 6 17:24:25 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 06 Mar 2006 12:24:25 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <1141413558.4694.24.camel@cutter> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> Message-ID: <440C7049.6040306@redhat.com> After reading this thread, I think that I should explain a little more what I was suggesting: o That we have a repository to support making our mobile support much better. Updated packages might include: NetworkManager kernel acpi-related stuff wpa_supplicant new X drivers suspend/resume scripts etc But that it's focused in this one area. Having a generic "experimental" tree will just result in piling on, and I would rather have focus in this one problem domain for this one repo. And also the "experimental" tree _is_ the devel tree. It's FC6. I just want to see us make real gains with the relatively stable FC5 tree. --Chris From jspaleta at gmail.com Mon Mar 6 19:58:11 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 6 Mar 2006 14:58:11 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <440C7049.6040306@redhat.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> Message-ID: <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> On 3/6/06, Christopher Blizzard wrote: > But that it's focused in this one area. Having a generic "experimental" > tree will just result in piling on, and I would rather have focus in > this one problem domain for this one repo. And also the "experimental" > tree _is_ the devel tree. It's FC6. I just want to see us make real > gains with the relatively stable FC5 tree. Isn't the people.redhat.com space the most appropriate place for this. As an example, Linville already runs http://people.redhat.com/linville/kernels/fedora-netdev/ as a yum repository for "experimental" kernels associated with network driver patches and has annoucements to the fedora-annouce list when there are updates. I'm not sure what "official blessing" you are looking for. What's stopping you from putting a similiar repo in your people.redhat.com space and pushing annoucements to the annouce-list in a similiar fashion to what linville has done for the kernel-netdev tree? -jef From nicolas.mailhot at laposte.net Mon Mar 6 20:18:35 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 06 Mar 2006 21:18:35 +0100 Subject: continuing with sprint development post-fc5 In-Reply-To: <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> Message-ID: <1141676315.17533.2.camel@rousalka.dyndns.org> Le lundi 06 mars 2006 ? 14:58 -0500, Jeff Spaleta a ?crit : > On 3/6/06, Christopher Blizzard wrote: > > But that it's focused in this one area. Having a generic "experimental" > > tree will just result in piling on, and I would rather have focus in > > this one problem domain for this one repo. And also the "experimental" > > tree _is_ the devel tree. It's FC6. I just want to see us make real > > gains with the relatively stable FC5 tree. > > Isn't the people.redhat.com space the most appropriate place for this. Some sort of official blessing and infrastructure to setup/teardown repos would be probably easier on users and packagers. Also, I seem to remember mharris for example was forced to make only a part of his xorg experimental work public because he was hitting prc quotas -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From blizzard at redhat.com Mon Mar 6 20:21:06 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 06 Mar 2006 15:21:06 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> Message-ID: <440C99B2.9090600@redhat.com> Jeff Spaleta wrote: > > Isn't the people.redhat.com space the most appropriate place for this. > > As an example, Linville already runs > http://people.redhat.com/linville/kernels/fedora-netdev/ > as a yum repository for "experimental" kernels associated with network > driver patches and has annoucements to the fedora-annouce list when > there are updates. > > I'm not sure what "official blessing" you are looking for. What's > stopping you from putting a similiar repo in your people.redhat.com > space and pushing annoucements to the annouce-list in a similiar > fashion to what linville has done for the kernel-netdev tree? > Stick it on download.fedora.redhat.com somewhere, have a page on fedoraprojects.org, etc. This is something that more than one person is taking part in, and we want to draw in more people from the community. To me it feels like sticking it on p.r.c just turns it into a one-man-band. --Chris From jkeating at j2solutions.net Mon Mar 6 20:32:07 2006 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 06 Mar 2006 12:32:07 -0800 Subject: continuing with sprint development post-fc5 In-Reply-To: <440C99B2.9090600@redhat.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> <440C99B2.9090600@redhat.com> Message-ID: <1141677127.4451.54.camel@ender> On Mon, 2006-03-06 at 15:21 -0500, Christopher Blizzard wrote: > > > Stick it on download.fedora.redhat.com somewhere, have a page on > fedoraprojects.org, etc. This is something that more than one person is > taking part in, and we want to draw in more people from the community. > To me it feels like sticking it on p.r.c just turns it into a one-man-band. Rel-eng can get more involved too, by creating build roots that include these updated packages and being able to use our build system to kick out the packages, also doing 'releases' to automate making yum repos for these, and then publishing them w/ nightly change announcements and such. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Mon Mar 6 20:42:25 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 06 Mar 2006 15:42:25 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <440C7049.6040306@redhat.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> Message-ID: <1141677745.2338.16.camel@orodruin.boston.redhat.com> On Mon, 2006-03-06 at 12:24 -0500, Christopher Blizzard wrote: > After reading this thread, I think that I should explain a little more > what I was suggesting: > > o That we have a repository to support making our mobile support much > better. Updated packages might include: [snip] > But that it's focused in this one area. Having a generic "experimental" > tree will just result in piling on, and I would rather have focus in > this one problem domain for this one repo. And also the "experimental" > tree _is_ the devel tree. It's FC6. I just want to see us make real > gains with the relatively stable FC5 tree. I really think the way to do this is to actually do the work in the devel tree and then once a specific thing is working better, look at how to get the changes back and use updates-testing and then the regular updates tree. Trying to have YAT[1] is just going to divide the work that much more into happening in different places and end up with a less good solution at the end. Jeremy [1] Yet Another Tree. From roozbeh at farsiweb.info Mon Mar 6 21:07:28 2006 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Tue, 07 Mar 2006 00:37:28 +0330 Subject: continuing with sprint development post-fc5 In-Reply-To: <1141677745.2338.16.camel@orodruin.boston.redhat.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> <1141677745.2338.16.camel@orodruin.boston.redhat.com> Message-ID: <1141679248.8731.5.camel@tameshk.farsiweb.info> ??? ??????? 2006-03-06 ???? 15:42 -0500? Jeremy Katz ????: > I really think the way to do this is to actually do the work in the > devel tree and then once a specific thing is working better, look at how > to get the changes back and use updates-testing and then the regular > updates tree. Trying to have YAT[1] is just going to divide the work > that much more into happening in different places and end up with a less > good solution at the end. +1 roozbeh From mharris at mharris.ca Tue Mar 7 01:09:42 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 06 Mar 2006 20:09:42 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> Message-ID: <440CDD56.6060101@mharris.ca> Jeff Spaleta wrote: > On 3/6/06, Christopher Blizzard wrote: > >>But that it's focused in this one area. Having a generic "experimental" >>tree will just result in piling on, and I would rather have focus in >>this one problem domain for this one repo. And also the "experimental" >>tree _is_ the devel tree. It's FC6. I just want to see us make real >>gains with the relatively stable FC5 tree. > > > Isn't the people.redhat.com space the most appropriate place for this. Not really. people.redhat.com is supposed to be the personal space for Red Hat employees to put their own whatevers. It isn't an official place for yum repositories, but since there is no official location, many of us have put up repositories or whatnot on people.redhat.com due to lack of a better place. To make things worse however, the people.redhat.com machine is almost out of disk space, and most people have fairly low disk quotas, which make it infeasible. I'm told that adding more disk space to the machine is not as simple as dropping in a new drive, and so we can't really rely on people.redhat.com being a place for yum repositories. What we really need, is a new machine with a LOT of disk space, and either no disk quotas, or very large disk quotas that do not restrict people from being able to do their jobs effectively. > As an example, Linville already runs > http://people.redhat.com/linville/kernels/fedora-netdev/ > as a yum repository for "experimental" kernels associated with network > driver patches and has annoucements to the fedora-annouce list when > there are updates. > > I'm not sure what "official blessing" you are looking for. What's > stopping you from putting a similiar repo in your people.redhat.com > space and pushing annoucements to the annouce-list in a similiar > fashion to what linville has done for the kernel-netdev tree? See above disk space/quota contraints, et al. Fedora currently does not have any official public place where developers can put stuff that is experimental or unofficial. I'm considering changing my scripts to push things to mharris.ca or to freedesktop.org instead, as both have essentially infinite disk space, and no quotas. What's funnier, is that I (and I assume most employees) can easily afford to purchase 50 times the disk space people.redhat.com has for our own personal use, but for some reason the company can't afford to provide public disk space for Fedora development, which is available for for all employees. ;o) Maybe this will change now that I've brought it up. ;o) -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From mharris at mharris.ca Tue Mar 7 01:11:16 2006 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 06 Mar 2006 20:11:16 -0500 Subject: continuing with sprint development post-fc5 In-Reply-To: <1141676315.17533.2.camel@rousalka.dyndns.org> References: <4406F784.4080400@redhat.com> <604aa7910603020825g1d706180x161f924920db034f@mail.gmail.com> <1141319462.2319.15.camel@localhost.localdomain> <1141323657.21012.10.camel@rousalka.dyndns.org> <440790AD.2060106@mharris.ca> <1141366782.29413.25.camel@thl.ct.heise.de> <44089248.1010706@fedoraproject.org> <1141413558.4694.24.camel@cutter> <440C7049.6040306@redhat.com> <604aa7910603061158m3ef5b97atdfdea83af2e1f818@mail.gmail.com> <1141676315.17533.2.camel@rousalka.dyndns.org> Message-ID: <440CDDB4.1090404@mharris.ca> Nicolas Mailhot wrote: > Le lundi 06 mars 2006 ? 14:58 -0500, Jeff Spaleta a ?crit : > >>On 3/6/06, Christopher Blizzard wrote: >> >>>But that it's focused in this one area. Having a generic "experimental" >>>tree will just result in piling on, and I would rather have focus in >>>this one problem domain for this one repo. And also the "experimental" >>>tree _is_ the devel tree. It's FC6. I just want to see us make real >>>gains with the relatively stable FC5 tree. >> >>Isn't the people.redhat.com space the most appropriate place for this. > > > Some sort of official blessing and infrastructure to setup/teardown > repos would be probably easier on users and packagers. > Also, I seem to remember mharris for example was forced to make only a > part of his xorg experimental work public because he was hitting prc > quotas Yep, and I think I have more disk quota allocated than anyone else on the machine (2Gb). Modular X will greatly reduce the amount of space I previously needed, except for RHEL3/4 updates, but I'm looking at moving my public rpms to mharris.ca instead. -- Mike A. Harris * Open Source Advocate * http://mharris.ca Proud Canadian. From SteveD at redhat.com Tue Mar 7 17:53:57 2006 From: SteveD at redhat.com (Steve Dickson) Date: Tue, 07 Mar 2006 12:53:57 -0500 Subject: New IBM T42p Hangs consistently with yesterday's rawhide Message-ID: <440DC8B5.7090000@RedHat.com> Hey... I installed yesterday's rawhide on an brand new IBM T42p laptop and it continues to hang in both gnome and kde after several movements of the mouse. I'm pretty sure its not the kernel since the hang happens on both 2009 and 1955 kernels... Now it well could be flaky hardware... since its new hardware but it well could not be... anybody else seeing a similar hang? If so is there an outstanding bz? if not I'll open one... Also note, this laptop has 1.5 GIG of memory... which is a bit strange... steved. From kwade at redhat.com Thu Mar 9 19:02:18 2006 From: kwade at redhat.com (Karsten Wade) Date: Thu, 09 Mar 2006 11:02:18 -0800 Subject: [WIKI SNAP] FC 5 latest release notes >23:59 UTC today Message-ID: <1141930938.3391.156.camel@erato.phig.org> http://fedoraproject.org/wiki/Docs/Beats Later today ... or tonight ... depending on flurries of activity from ya'll, we are going to freeze the release notes beats for an edit pass prior to putting out another round of XML. Next week, with the FC 5 launch, we are going to be posting this latest release notes. The URL is prominently at the top of the release notes on the installed system. Once we unlock the Wiki, you can continue to put in changes for FC 5. If they are crucial for launch, please note that in the the changelog message, and consider filing a bug report against the release-notes component of Fedora Documentation. We have this Web launch precisely so we can be flexible up to the last few days before release to get in crucial, important, and timely information. Just don't be abusive. :) Thanks again to all of you for your support and contributions. Best. Release Notes. Ever. - Karsten Cc: fedora-devel-list and os-devel-list (separately) -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From katzj at redhat.com Fri Mar 10 15:53:52 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 10 Mar 2006 10:53:52 -0500 Subject: Fedora Core 5 Status Message-ID: <1142006032.29247.10.camel@orodruin.boston.redhat.com> Due to circumstances outside of our control, we're going to be unable to keep to the scheduled date of March 15th for the release of FC5 and instead are going to have to make the release date Monday, March 20th. While unfortunate in some ways, this gives us the opportunity to pull in the final GNOME 2.14 tarballs which should be available on Monday assuming the changes are suitably minor. Jeremy From kwade at redhat.com Fri Mar 10 17:08:55 2006 From: kwade at redhat.com (Karsten Wade) Date: Fri, 10 Mar 2006 09:08:55 -0800 Subject: [WIKI SNAP] FC 5 latest release notes >23:59 UTC today In-Reply-To: <1141930938.3391.156.camel@erato.phig.org> References: <1141930938.3391.156.camel@erato.phig.org> Message-ID: <1142010536.9552.81.camel@erato.phig.org> On Thu, 2006-03-09 at 11:02 -0800, Karsten Wade wrote: > http://fedoraproject.org/wiki/Docs/Beats > > Later today ... or tonight ... depending on flurries of activity from > ya'll, we are going to freeze the release notes beats for an edit pass > prior to putting out another round of XML. Considering that the FC5 launch is postponed until 20 March, we are going to unfreeze the Docs/Beats pages in the Wiki until this coming Monday or Tuesday. We shall then do a final edit through and conversion to XML for the Web launch. - Karsten 100% carefully triple-posted content! -- Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41 Content Services Fedora Documentation Project http://www.redhat.com/docs http://fedoraproject.org/wiki/DocsProject -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dcbw at redhat.com Mon Mar 13 05:12:33 2006 From: dcbw at redhat.com (Dan Williams) Date: Mon, 13 Mar 2006 00:12:33 -0500 Subject: Buildsystem maintenance Monday, March 13th Message-ID: <1142226753.13182.22.camel@localhost.localdomain> Hi, I'll be updating the buildsystem to plague 0.4.4 on Monday morning. This update will enable kmod builds. Downtime shouldn't be more than an hour, beginning around 9:30 AM US EST. Dan From orion at cora.nwra.com Wed Mar 15 17:54:45 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 15 Mar 2006 10:54:45 -0700 Subject: Need help with library issue on x86_64 Message-ID: <441854E5.20606@cora.nwra.com> I maintain the hdf5 library for extras. On a recent update, the FC3/4/5 x86_64 version broke (actually, don't know exactly when it broke, but fairly recently): *** Warning: This library needs some functionality provided by -lpthread. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lssl. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lcrypto. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lz. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** Warning: This library needs some functionality provided by -lm. *** I have the capability to make that library automatically link in when *** you link to this library. But I can only do this if you have a *** shared version of the library, which you do not appear to have. *** The inter-library dependencies that have been dropped here will be *** automatically added whenever a program is linked with this library *** or is declared to -dlopen it. gcc -shared H5.lo H5A.lo H5AC.lo H5B.lo H5C.lo H5D.lo H5Dcontig.lo H5Dcompact.lo H5Defl.lo H5Dio.lo H5Distore.lo H5Dmpio.lo H5Dselect.lo H5Dtest.lo H5E.lo H5F.lo H5Fdbg.lo H5Fmount.lo H5Fsfile.lo H5Fsuper.lo H5FD.lo H5FDcore.lo H5FDfamily.lo H5FDgass.lo H5FDlog.lo H5FDmpi.lo H5FDmpio.lo H5FDmpiposix.lo H5FDmulti.lo H5FDsec2.lo H5FDsrb.lo H5FDstdio.lo H5FDstream.lo H5FL.lo H5FO.lo H5FS.lo H5G.lo H5Gent.lo H5Gnode.lo H5Gstab.lo H5HG.lo H5HGdbg.lo H5HL.lo H5HLdbg.lo H5HP.lo H5I.lo H5MF.lo H5MM.lo H5O.lo H5Oattr.lo H5Obogus.lo H5Ocont.lo H5Odtype.lo H5Oefl.lo H5Ofill.lo H5Olayout.lo H5Omtime.lo H5Oname.lo H5Onull.lo H5Opline.lo H5Osdspace.lo H5Oshared.lo H5Ostab.lo H5P.lo H5Pdcpl.lo H5Pdxpl.lo H5Pfapl.lo H5Pfcpl.lo H5Ptest.lo H5R.lo H5RC.lo H5RS.lo H5S.lo H5Sall.lo H5Shyper.lo H5Smpio.lo H5Snone.lo H5Spoint.lo H5Sselect.lo H5Stest.lo H5SL.lo H5ST.lo H5T.lo H5Tarray.lo H5Tbit.lo H5Tcommit.lo H5Tcompound.lo H5Tconv.lo H5Tcset.lo H5Tenum.lo H5Tfields.lo H5Tfixed.lo H5Tfloat.lo H5Tinit.lo H5Tnative.lo H5Toffset.lo H5Topaque.lo H5Torder.lo H5Tpad.lo H5Tprecis.lo H5Tstrpad.lo H5Tvlen.lo H5TS.lo H5V.lo H5Z.lo H5Zdeflate.lo H5Zfletcher32.lo H5Zshuffle.lo H5Zszip.lo -Wl,-soname -Wl,libhdf5.so.0 -o .libs/libhdf5.so.0.0.0 As a result, the library does not bring in dependencies automatically: $ ldd /usr/lib64/libhdf5.so.0.0.0 ldd: warning: you do not have execution permission for `/usr/lib64/libhdf5.so.0.0.0' libc.so.6 => /lib64/libc.so.6 (0x00002aaaaacd7000) /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) It works fine on i386 and ppc. I really have no idea where to look next... This is a libtool issue, right? On the other platforms the link line lists the libraries: gcc -shared H5.lo H5A.lo H5AC.lo H5B.lo H5C.lo H5D.lo H5Dcontig.lo H5Dcompact.lo H5Defl.lo H5Dio.lo H5Distore.lo H5Dmpio.lo H5Dselect.lo H5Dtest.lo H5E.lo H5F.lo H5Fdbg.lo H5Fmount.lo H5Fsfile.lo H5Fsuper.lo H5FD.lo H5FDcore.lo H5FDfamily.lo H5FDgass.lo H5FDlog.lo H5FDmpi.lo H5FDmpio.lo H5FDmpiposix.lo H5FDmulti.lo H5FDsec2.lo H5FDsrb.lo H5FDstdio.lo H5FDstream.lo H5FL.lo H5FO.lo H5FS.lo H5G.lo H5Gent.lo H5Gnode.lo H5Gstab.lo H5HG.lo H5HGdbg.lo H5HL.lo H5HLdbg.lo H5HP.lo H5I.lo H5MF.lo H5MM.lo H5O.lo H5Oattr.lo H5Obogus.lo H5Ocont.lo H5Odtype.lo H5Oefl.lo H5Ofill.lo H5Olayout.lo H5Omtime.lo H5Oname.lo H5Onull.lo H5Opline.lo H5Osdspace.lo H5Oshared.lo H5Ostab.lo H5P.lo H5Pdcpl.lo H5Pdxpl.lo H5Pfapl.lo H5Pfcpl.lo H5Ptest.lo H5R.lo H5RC.lo H5RS.lo H5S.lo H5Sall.lo H5Shyper.lo H5Smpio.lo H5Snone.lo H5Spoint.lo H5Sselect.lo H5Stest.lo H5SL.lo H5ST.lo H5T.lo H5Tarray.lo H5Tbit.lo H5Tcommit.lo H5Tcompound.lo H5Tconv.lo H5Tcset.lo H5Tenum.lo H5Tfields.lo H5Tfixed.lo H5Tfloat.lo H5Tinit.lo H5Tnative.lo H5Toffset.lo H5Topaque.lo H5Torder.lo H5Tpad.lo H5Tprecis.lo H5Tstrpad.lo H5Tvlen.lo H5TS.lo H5V.lo H5Z.lo H5Zdeflate.lo H5Zfletcher32.lo H5Zshuffle.lo H5Zszip.lo -lpthread -lssl -lcrypto -lz -lm -Wl,-soname -Wl,libhdf5.so.0 -o .libs/libhdf5.so.0.0.0 -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From j.w.r.degoede at hhs.nl Wed Mar 15 18:14:53 2006 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Wed, 15 Mar 2006 19:14:53 +0100 Subject: Need help with library issue on x86_64 In-Reply-To: <441854E5.20606@cora.nwra.com> References: <441854E5.20606@cora.nwra.com> Message-ID: <4418599D.2050300@hhs.nl> Are all the .o files for the library compiled with -fPIC? You can usually get away with forgetting -fPIC for i386 but not for x86_64. Regards, Hans Orion Poplawski wrote: > I maintain the hdf5 library for extras. On a recent update, the FC3/4/5 > x86_64 version broke (actually, don't know exactly when it broke, but > fairly recently): > > *** Warning: This library needs some functionality provided by -lpthread. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: This library needs some functionality provided by -lssl. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: This library needs some functionality provided by -lcrypto. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: This library needs some functionality provided by -lz. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > > *** Warning: This library needs some functionality provided by -lm. > *** I have the capability to make that library automatically link in when > *** you link to this library. But I can only do this if you have a > *** shared version of the library, which you do not appear to have. > *** The inter-library dependencies that have been dropped here will be > *** automatically added whenever a program is linked with this library > *** or is declared to -dlopen it. > gcc -shared H5.lo H5A.lo H5AC.lo H5B.lo H5C.lo H5D.lo H5Dcontig.lo > H5Dcompact.lo H5Defl.lo H5Dio.lo H5Distore.lo H5Dmpio.lo H5Dselect.lo > H5Dtest.lo H5E.lo H5F.lo H5Fdbg.lo H5Fmount.lo H5Fsfile.lo H5Fsuper.lo > H5FD.lo H5FDcore.lo H5FDfamily.lo H5FDgass.lo H5FDlog.lo H5FDmpi.lo > H5FDmpio.lo H5FDmpiposix.lo H5FDmulti.lo H5FDsec2.lo H5FDsrb.lo > H5FDstdio.lo H5FDstream.lo H5FL.lo H5FO.lo H5FS.lo H5G.lo H5Gent.lo > H5Gnode.lo H5Gstab.lo H5HG.lo H5HGdbg.lo H5HL.lo H5HLdbg.lo H5HP.lo > H5I.lo H5MF.lo H5MM.lo H5O.lo H5Oattr.lo H5Obogus.lo H5Ocont.lo > H5Odtype.lo H5Oefl.lo H5Ofill.lo H5Olayout.lo H5Omtime.lo H5Oname.lo > H5Onull.lo H5Opline.lo H5Osdspace.lo H5Oshared.lo H5Ostab.lo H5P.lo > H5Pdcpl.lo H5Pdxpl.lo H5Pfapl.lo H5Pfcpl.lo H5Ptest.lo H5R.lo H5RC.lo > H5RS.lo H5S.lo H5Sall.lo H5Shyper.lo H5Smpio.lo H5Snone.lo H5Spoint.lo > H5Sselect.lo H5Stest.lo H5SL.lo H5ST.lo H5T.lo H5Tarray.lo H5Tbit.lo > H5Tcommit.lo H5Tcompound.lo H5Tconv.lo H5Tcset.lo H5Tenum.lo > H5Tfields.lo H5Tfixed.lo H5Tfloat.lo H5Tinit.lo H5Tnative.lo > H5Toffset.lo H5Topaque.lo H5Torder.lo H5Tpad.lo H5Tprecis.lo > H5Tstrpad.lo H5Tvlen.lo H5TS.lo H5V.lo H5Z.lo H5Zdeflate.lo > H5Zfletcher32.lo H5Zshuffle.lo H5Zszip.lo -Wl,-soname -Wl,libhdf5.so.0 > -o .libs/libhdf5.so.0.0.0 > > As a result, the library does not bring in dependencies automatically: > > $ ldd /usr/lib64/libhdf5.so.0.0.0 > ldd: warning: you do not have execution permission for > `/usr/lib64/libhdf5.so.0.0.0' > libc.so.6 => /lib64/libc.so.6 (0x00002aaaaacd7000) > /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) > > It works fine on i386 and ppc. > > I really have no idea where to look next... This is a libtool issue, > right? On the other platforms the link line lists the libraries: > > gcc -shared H5.lo H5A.lo H5AC.lo H5B.lo H5C.lo H5D.lo H5Dcontig.lo > H5Dcompact.lo H5Defl.lo H5Dio.lo H5Distore.lo H5Dmpio.lo H5Dselect.lo > H5Dtest.lo H5E.lo H5F.lo H5Fdbg.lo H5Fmount.lo H5Fsfile.lo H5Fsuper.lo > H5FD.lo H5FDcore.lo H5FDfamily.lo H5FDgass.lo H5FDlog.lo H5FDmpi.lo > H5FDmpio.lo H5FDmpiposix.lo H5FDmulti.lo H5FDsec2.lo H5FDsrb.lo > H5FDstdio.lo H5FDstream.lo H5FL.lo H5FO.lo H5FS.lo H5G.lo H5Gent.lo > H5Gnode.lo H5Gstab.lo H5HG.lo H5HGdbg.lo H5HL.lo H5HLdbg.lo H5HP.lo > H5I.lo H5MF.lo H5MM.lo H5O.lo H5Oattr.lo H5Obogus.lo H5Ocont.lo > H5Odtype.lo H5Oefl.lo H5Ofill.lo H5Olayout.lo H5Omtime.lo H5Oname.lo > H5Onull.lo H5Opline.lo H5Osdspace.lo H5Oshared.lo H5Ostab.lo H5P.lo > H5Pdcpl.lo H5Pdxpl.lo H5Pfapl.lo H5Pfcpl.lo H5Ptest.lo H5R.lo H5RC.lo > H5RS.lo H5S.lo H5Sall.lo H5Shyper.lo H5Smpio.lo H5Snone.lo H5Spoint.lo > H5Sselect.lo H5Stest.lo H5SL.lo H5ST.lo H5T.lo H5Tarray.lo H5Tbit.lo > H5Tcommit.lo H5Tcompound.lo H5Tconv.lo H5Tcset.lo H5Tenum.lo > H5Tfields.lo H5Tfixed.lo H5Tfloat.lo H5Tinit.lo H5Tnative.lo > H5Toffset.lo H5Topaque.lo H5Torder.lo H5Tpad.lo H5Tprecis.lo > H5Tstrpad.lo H5Tvlen.lo H5TS.lo H5V.lo H5Z.lo H5Zdeflate.lo > H5Zfletcher32.lo H5Zshuffle.lo H5Zszip.lo -lpthread -lssl -lcrypto -lz > -lm -Wl,-soname -Wl,libhdf5.so.0 -o .libs/libhdf5.so.0.0.0 > From dennis at ausil.us Wed Mar 15 18:21:08 2006 From: dennis at ausil.us (Dennis Gilmore) Date: Wed, 15 Mar 2006 12:21:08 -0600 Subject: Need help with library issue on x86_64 In-Reply-To: <441854E5.20606@cora.nwra.com> References: <441854E5.20606@cora.nwra.com> Message-ID: <200603151221.08594.dennis@ausil.us> On Wednesday 15 March 2006 11:54, Orion Poplawski wrote: > I maintain the hdf5 library for extras. On a recent update, the FC3/4/5 > x86_64 version broke (actually, don't know exactly when it broke, but > fairly recently): > As a result, the library does not bring in dependencies automatically: > > $ ldd /usr/lib64/libhdf5.so.0.0.0 > ldd: warning: you do not have execution permission for > `/usr/lib64/libhdf5.so.0.0.0' > libc.so.6 => /lib64/libc.so.6 (0x00002aaaaacd7000) > /lib64/ld-linux-x86-64.so.2 (0x0000555555554000) > > It works fine on i386 and ppc. My guess its its hardcoded somewhere to look in /lib and /usr/lib you will need to make sure it looks in /lib64 and /usr/lib64 also -- Regards Dennis Gilmore, RHCE Proud Australian From orion at cora.nwra.com Wed Mar 15 18:50:02 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 15 Mar 2006 11:50:02 -0700 Subject: Need help with library issue on x86_64 In-Reply-To: <200603151221.08594.dennis@ausil.us> References: <441854E5.20606@cora.nwra.com> <200603151221.08594.dennis@ausil.us> Message-ID: <441861DA.3040106@cora.nwra.com> Dennis Gilmore wrote: > My guess its its hardcoded somewhere to look in /lib and /usr/lib you will > need to make sure it looks in /lib64 and /usr/lib64 also > Indeed it is in aclocal.m4. Yeesh. So, do I patch aclocal.m4 to use /lib64 and /usr/lib64 or is there a better way to detect this automatically? Thanks! -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From arjan at fenrus.demon.nl Wed Mar 15 18:56:28 2006 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 15 Mar 2006 19:56:28 +0100 Subject: Need help with library issue on x86_64 In-Reply-To: <441861DA.3040106@cora.nwra.com> References: <441854E5.20606@cora.nwra.com> <200603151221.08594.dennis@ausil.us> <441861DA.3040106@cora.nwra.com> Message-ID: <1142448988.3021.41.camel@laptopd505.fenrus.org> On Wed, 2006-03-15 at 11:50 -0700, Orion Poplawski wrote: > Dennis Gilmore wrote: > > My guess its its hardcoded somewhere to look in /lib and /usr/lib you will > > need to make sure it looks in /lib64 and /usr/lib64 also > > > > Indeed it is in aclocal.m4. Yeesh. So, do I patch aclocal.m4 to use > /lib64 and /usr/lib64 or is there a better way to detect this automatically? usually just removing the dir entirely just works... the linker is not stupid and does the right thing From orion at cora.nwra.com Wed Mar 15 20:53:38 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 15 Mar 2006 13:53:38 -0700 Subject: Need help with library issue on x86_64 In-Reply-To: <1142448988.3021.41.camel@laptopd505.fenrus.org> References: <441854E5.20606@cora.nwra.com> <200603151221.08594.dennis@ausil.us> <441861DA.3040106@cora.nwra.com> <1142448988.3021.41.camel@laptopd505.fenrus.org> Message-ID: <44187ED2.3090808@cora.nwra.com> Arjan van de Ven wrote: > > usually just removing the dir entirely just works... the linker is not > stupid and does the right thing While the linker is not stupid, this libtool is. It insists on scanning a list of directories for the libraries and only linking with them if it finds them. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From qspencer at ieee.org Wed Mar 15 21:10:42 2006 From: qspencer at ieee.org (Quentin Spencer) Date: Wed, 15 Mar 2006 15:10:42 -0600 Subject: Need help with library issue on x86_64 In-Reply-To: <44187ED2.3090808@cora.nwra.com> References: <441854E5.20606@cora.nwra.com> <200603151221.08594.dennis@ausil.us> <441861DA.3040106@cora.nwra.com> <1142448988.3021.41.camel@laptopd505.fenrus.org> <44187ED2.3090808@cora.nwra.com> Message-ID: <441882D2.7020906@ieee.org> Orion Poplawski wrote: > Arjan van de Ven wrote: > >> >> usually just removing the dir entirely just works... the linker is not >> stupid and does the right thing > > > While the linker is not stupid, this libtool is. It insists on > scanning a list of directories for the libraries and only linking with > them if it finds them. > This is from the same upstream authors that decided that if you're building on i686, then you should definitely add -march=i686 to the compile flags regardless of the flags the user has already decided to use. Out of curiosity, I just looked at the Debian patches and noticed that they have heavily patched this file--you might look at what they are doing for a solution: http://ftp.debian.org/debian/pool/main/h/hdf5/hdf5_1.6.4-4.diff.gz -Quentin From rdieter at math.unl.edu Wed Mar 15 21:12:50 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 15 Mar 2006 15:12:50 -0600 Subject: Need help with library issue on x86_64 In-Reply-To: <44187ED2.3090808@cora.nwra.com> References: <441854E5.20606@cora.nwra.com> <200603151221.08594.dennis@ausil.us> <441861DA.3040106@cora.nwra.com> <1142448988.3021.41.camel@laptopd505.fenrus.org> <44187ED2.3090808@cora.nwra.com> Message-ID: <44188352.2020007@math.unl.edu> Orion Poplawski wrote: > Arjan van de Ven wrote: > >> >> usually just removing the dir entirely just works... the linker is not >> stupid and does the right thing > > > While the linker is not stupid, this libtool is. It insists on scanning > a list of directories for the libraries and only linking with them if it > finds them. I had a similar problem with gc/x86_64 awhile back. Updating the auto*/libtool toolchain bits fixed it for me: In %setup after any patches, I do: cp -f %{_datadir}/aclocal/libtool.m4 . libtoolize --copy --force aclocal automake autoconf -- Rex From orion at cora.nwra.com Thu Mar 16 00:01:43 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 15 Mar 2006 17:01:43 -0700 Subject: Need help with library issue on x86_64 In-Reply-To: <44188352.2020007@math.unl.edu> References: <441854E5.20606@cora.nwra.com> <200603151221.08594.dennis@ausil.us> <441861DA.3040106@cora.nwra.com> <1142448988.3021.41.camel@laptopd505.fenrus.org> <44187ED2.3090808@cora.nwra.com> <44188352.2020007@math.unl.edu> Message-ID: <4418AAE7.2080006@cora.nwra.com> Rex Dieter wrote: > I had a similar problem with gc/x86_64 awhile back. Updating the > auto*/libtool toolchain bits fixed it for me: > > In %setup after any patches, I do: > > cp -f %{_datadir}/aclocal/libtool.m4 . > libtoolize --copy --force > aclocal > automake > autoconf Depends on how much mucking with the autotools upstream does. Can lead to other problems. But it works and is easy in some cases. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From katzj at redhat.com Thu Mar 16 18:31:36 2006 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 16 Mar 2006 13:31:36 -0500 Subject: CVS Branching for FC/FE 5 this afternoon Message-ID: <1142533896.23758.31.camel@orodruin.boston.redhat.com> I'm going to be doing the CVS branching for Fedora Core/Extras 5 this afternoon. While running the script for Extras, I will be locking access to CVS and the build system will be down. Also, I'll turn off syncmail to avoid spamming everyone with 1000 branch commits :) I expect to be starting this process at about 3 pm Eastern (2000 UTC) and it shouldn't take more than an hour. When things come back up (and I'll send mail at that time), builds for FE5 will need to be done separately from the development tree. Jeremy From gemi at bluewin.ch Thu Mar 16 18:43:19 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Thu, 16 Mar 2006 19:43:19 +0100 Subject: emacs 22 and FC In-Reply-To: <43CF4922.4040106@redhat.com> References: <43CF4922.4040106@redhat.com> Message-ID: <1142534599.12226.2.camel@scriabin.tannenrauch.ch> On Thu, 2006-01-19 at 17:09 +0900, Jens Petersen wrote: > As some of you are probably well aware, Emacs 22 seems to be taking forever > to be released, so some users are getting impatient to see a cvs snapshot My belated opinion: I would like to have Emacs 22 as soon as possible. I have you used your snapshot and it works well. I certainly prefer the GTK menus to the old emacs and xemacs ones. If only it had anti-aliased text... One problem though: I cannot use the compose key for entering latin-1 characters. The mini-buffer shows is undefined. -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From ville.skytta at iki.fi Thu Mar 16 20:20:55 2006 From: ville.skytta at iki.fi (Ville =?ISO-8859-1?Q?Skytt=E4?=) Date: Thu, 16 Mar 2006 22:20:55 +0200 Subject: emacs 22 and FC In-Reply-To: <1142534599.12226.2.camel@scriabin.tannenrauch.ch> References: <43CF4922.4040106@redhat.com> <1142534599.12226.2.camel@scriabin.tannenrauch.ch> Message-ID: <1142540455.5917.24.camel@bobcat.mine.nu> On Thu, 2006-03-16 at 19:43 +0100, G?rard Milmeister wrote: > I would like to have Emacs 22 as soon as possible. I have you used > your snapshot and it works well. I certainly prefer the GTK menus > to the old emacs and xemacs ones. > If only it had anti-aliased text... Regarding XEmacs, I plan to switch to the 21.5 beta series in post-FE5 devel. The most obvious highlights of 21.5.x over 21.4.x currently are improved Unicode support as well as eventually antialiased fonts. The latter is already included upstream, but not quite ready for prime time so at least in the first package incarnations it will probably be guarded by a command line switch to rpmbuild. 21.5 should also have improved GTK support, but unfortunately it's still GTK 1.x so chances are that I won't bother with it in the FE package. From jamatos at fc.up.pt Fri Mar 17 12:34:07 2006 From: jamatos at fc.up.pt (Jose' Matos) Date: Fri, 17 Mar 2006 12:34:07 +0000 Subject: emacs 22 and FC In-Reply-To: <1142534599.12226.2.camel@scriabin.tannenrauch.ch> References: <43CF4922.4040106@redhat.com> <1142534599.12226.2.camel@scriabin.tannenrauch.ch> Message-ID: <200603171234.07925.jamatos@fc.up.pt> On Thursday 16 March 2006 18:43, G?rard Milmeister wrote: > One problem though: > I cannot use the compose key for entering latin-1 characters. > The mini-buffer shows is undefined. I reported it previously to Jens, but I never got the time to report it upstream as Jens suggested. Everytime I try to insert ? (?+e) I get: is undefined The same happens for every other dead key. :( -- Jos? Ab?lio From katzj at redhat.com Mon Mar 20 16:59:57 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 20 Mar 2006 11:59:57 -0500 Subject: Wild and crazy times for the development tree Message-ID: <1142873997.3002.15.camel@aglarond.local> With the release of Fedora Core 5, the development tree is now open for things to continue forward. So if you've been following it purely to get updates for the FC5 test releases, you'll probably want to grab the fedora-release package from the FC5 release instead. If you want to keep testing and helping to develop things for Fedora Core 6, expect for some fun to pop up as always. Jeremy From dwalsh at redhat.com Thu Mar 23 14:31:19 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Mar 2006 09:31:19 -0500 Subject: Isn't it time for the encrypted file system??? Message-ID: <4422B137.6010000@redhat.com> Received an FedEX from Fidelity this morning seems, one of their laptops was stolen. On the laptop, was the Personal information, including Social Security number, of everyone in the HP Retirement plan (I suppose this includes DEC/Compaq and HP. They have us jumping through hoops and going to Credit Agencies to watch for unusual activity. Now if the system had been encrypted ... Now why was this data on a laptop? I don't know. Laptops have becoming the standard machine for people, replacing the desktop. We need to consider defaulting FC6 with encrypted filesystem or at least homedirs out of the box. This should be a key feature of FC6. Dan From skvidal at linux.duke.edu Thu Mar 23 19:05:32 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Thu, 23 Mar 2006 14:05:32 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <1143140732.32685.3.camel@cutter> On Thu, 2006-03-23 at 09:31 -0500, Daniel J Walsh wrote: > Received an FedEX from Fidelity this morning seems, one of their > laptops was stolen. On the laptop, was the Personal information, > including Social Security number, of everyone in the HP Retirement > plan (I suppose this includes DEC/Compaq and HP. They have us jumping > through hoops and going to Credit Agencies to watch for unusual activity. > Now if the system had been encrypted ... Now why was this data on a > laptop? I don't know. > > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted filesystem > or at least homedirs out of the box. This should be a key feature of FC6. Or maybe corporations handling that kind of data need to do take protective security measures for their installations of operating systems. if I were in the same position I would, of course, use encrypted file systems - but to have that overhead for the default is a bit extreme. Sounds like the IT group in corporation needs to stop being so naive. -sv From jspaleta at gmail.com Thu Mar 23 19:06:47 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 23 Mar 2006 14:06:47 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <604aa7910603231106p4b7d58a4oa66c7f6c141397a5@mail.gmail.com> On 3/23/06, Daniel J Walsh wrote: > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted filesystem > or at least homedirs out of the box. This should be a key feature of FC6. I'm not against the idea of encrypted home directories... even as defaults. But please can we make sure if this is going to happen there is an easily digestable option at install time to disable this? And is there an easy mechanim to revert back to an unencrypted system later (after a legit authing step of course)? -jef From mike at flyn.org Thu Mar 23 20:19:51 2006 From: mike at flyn.org (W. Michael Petullo) Date: Thu, 23 Mar 2006 14:19:51 -0600 (CST) Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <18172.160.136.109.101.1143145191.squirrel@zero.voxel.net> > Received an FedEX from Fidelity this morning seems, one of their > laptops was stolen. On the laptop, was the Personal information, > including Social Security number, of everyone in the HP Retirement > plan (I suppose this includes DEC/Compaq and HP. They have us jumping > through hoops and going to Credit Agencies to watch for unusual activity. > Now if the system had been encrypted ... Now why was this data on a > laptop? I don't know. > > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted filesystem > or at least homedirs out of the box. This should be a key feature of FC6. Please see: Encrypted swap https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=127378 Encrypted root filesystem https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=124789 Removable encrypted devices (Mostly done, thanks to David Zeuthen) http://www.flyn.org/easycrypto/easycrypto.html Implementing Encrypted Home Directories (using pam_mount) http://www.linuxjournal.com/article/6481 Encrypt Your Root Filesystem http://www.linuxjournal.com/article/7743 -- Mike Petullo From andreas.bierfert at lowlatency.de Thu Mar 23 21:29:47 2006 From: andreas.bierfert at lowlatency.de (Andreas Bierfert) Date: Thu, 23 Mar 2006 22:29:47 +0100 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <20060323222947.360373a3@alkaid.a.lan> On Thu, 23 Mar 2006 09:31:19 -0500 Daniel J Walsh wrote: > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted filesystem > or at least homedirs out of the box. This should be a key feature of FC6. Maybe not a default but having a system installation with encrypted filesystems, encrypted tmp and/or encrypted swap out of the box would be great... at least to have the option... - Andreas -- Andreas Bierfert | http://awbsworld.de | GPG: C58CF1CB andreas.bierfert at lowlatency.de | http://lowlatency.de | signed/encrypted phone: +49 2402 102373 | cell: +49 173 5803043 | mail preferred -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: not available URL: From pmatilai at laiskiainen.org Fri Mar 24 06:50:26 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 23 Mar 2006 22:50:26 -0800 (PST) Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143140732.32685.3.camel@cutter> References: <4422B137.6010000@redhat.com> <1143140732.32685.3.camel@cutter> Message-ID: On Thu, 23 Mar 2006, seth vidal wrote: > On Thu, 2006-03-23 at 09:31 -0500, Daniel J Walsh wrote: >> Received an FedEX from Fidelity this morning seems, one of their >> laptops was stolen. On the laptop, was the Personal information, >> including Social Security number, of everyone in the HP Retirement >> plan (I suppose this includes DEC/Compaq and HP. They have us jumping >> through hoops and going to Credit Agencies to watch for unusual activity. >> Now if the system had been encrypted ... Now why was this data on a >> laptop? I don't know. >> >> Laptops have becoming the standard machine for people, replacing the >> desktop. We need to consider defaulting FC6 with encrypted filesystem >> or at least homedirs out of the box. This should be a key feature of FC6. > > Or maybe corporations handling that kind of data need to do take > protective security measures for their installations of operating > systems. > > if I were in the same position I would, of course, use encrypted file > systems - but to have that overhead for the default is a bit extreme. We have a corporate policy requiring encryption of the *entire* disk (obviously /boot is an exception), not just /home. It may be a bit extreme but if you start encrypting stuff, /tmp, /var and swap are an absolute must to cover as well, otherwise you'll be leaking company secrets you viewed as mail attachmets to unencrypted /tmp etc. Oh btw, obviously there is a performance hit to encrypting everything but it's nowhere near as bad as one would think, in fact is almost unnoticeable on normal use. Sure, when running a fully encrypted system and testing another installation inside VMware which is also encrypting the disk it things start to get a little sluggish ;) Anyway, it would be very very nice to finally have fs encryption directly supported in FC. - Panu - From fedora at camperquake.de Fri Mar 24 08:14:06 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 24 Mar 2006 09:14:06 +0100 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <20060324091406.20ad750f@soran.addix.net> Hi. On Thu, 23 Mar 2006 09:31:19 -0500, Daniel J Walsh wrote: > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted > filesystem or at least homedirs out of the box. This should be a key > feature of FC6. All the bits and pieces are there, I think. What is missing is and easily usable switch. There is even an article in the RHKB describing how to encrypt a LV under RHEL4. From nicolas.mailhot at laposte.net Fri Mar 24 09:02:46 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 24 Mar 2006 10:02:46 +0100 (CET) Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143140732.32685.3.camel@cutter> References: <4422B137.6010000@redhat.com> <1143140732.32685.3.camel@cutter> Message-ID: <8086.192.54.193.25.1143190966.squirrel@rousalka.dyndns.org> Le Jeu 23 mars 2006 20:05, seth vidal a ?crit : > if I were in the same position I would, of course, use encrypted file > systems - but to have that overhead for the default is a bit extreme. > > Sounds like the IT group in corporation needs to stop being so naive. What I find na?ve is continuing to believe security can be special-cased. Do you think company users bother to report every single security-sensitive documents they manipulate ? Do you think home users think about it ? Either you do it for everyone and it has a chance to be in place when it'll really be needed or you shouldn't bother at all. The kind of bureaucracy that would be needed to identify exactly what bits needed to be protected is just never going to happen. -- Nicolas Mailhot From stickster at gmail.com Fri Mar 24 15:53:07 2006 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 24 Mar 2006 10:53:07 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <1143215588.4912.3.camel@localhost.localdomain> On Thu, 2006-03-23 at 09:31 -0500, Daniel J Walsh wrote: > Received an FedEX from Fidelity this morning seems, one of their > laptops was stolen. On the laptop, was the Personal information, > including Social Security number, of everyone in the HP Retirement > plan (I suppose this includes DEC/Compaq and HP. They have us jumping > through hoops and going to Credit Agencies to watch for unusual activity. > Now if the system had been encrypted ... Now why was this data on a > laptop? I don't know. > > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted filesystem > or at least homedirs out of the box. This should be a key feature of FC6. As long as there's a clear visible option to do away with encryption on the FS, that's cool. Deciding to put important data in a possibly unretrievable state in the event of a user departure from a company or an untimely demise is not a great idea without a plan to recover it. My laptop is owned by my company, and I am sure they don't want me encrypting data on it in a manner which prevents them from accessing it should they wish to. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From kzak at redhat.com Fri Mar 24 16:50:41 2006 From: kzak at redhat.com (Karel Zak) Date: Fri, 24 Mar 2006 17:50:41 +0100 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <4422B137.6010000@redhat.com> References: <4422B137.6010000@redhat.com> Message-ID: <20060324165041.GB8291@petra.dvoda.cz> On Thu, Mar 23, 2006 at 09:31:19AM -0500, Daniel J Walsh wrote: > Laptops have becoming the standard machine for people, replacing the > desktop. We need to consider defaulting FC6 with encrypted filesystem > or at least homedirs out of the box. This should be a key feature of FC6. I don't think that encrypted filesystem is a good way. I think better idea is support for encrypted devices (partitions). It's solution independent on filesystem and it's useful for swaps too. For more details see cryptsetup-luks and dm-crypt. I have done work on util-linux patch that adds full cryptsetup-luks support to mount, umount, swapon and swapoff. See: http://people.redhat.com/kzak/util-linux-cryptsetup/ I'd like to see it in the util-linux upstream, but upstream seems pretty inactive... Maybe we can try it as FC specific solution and don't wait for any external (upstream) solution. Karel -- Karel Zak From skvidal at linux.duke.edu Fri Mar 24 18:28:42 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 24 Mar 2006 13:28:42 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: References: <4422B137.6010000@redhat.com> <1143140732.32685.3.camel@cutter> Message-ID: <1143224922.4336.38.camel@cutter> On Thu, 2006-03-23 at 22:50 -0800, Panu Matilainen wrote: > We have a corporate policy requiring encryption of the *entire* disk > (obviously /boot is an exception), not just /home. It may be a bit > extreme but if you start encrypting stuff, /tmp, /var and swap are an > absolute must to cover as well, otherwise you'll be leaking company > secrets you viewed as mail attachmets to unencrypted /tmp etc. > > Oh btw, obviously there is a performance hit to encrypting everything but > it's nowhere near as bad as one would think, in fact is almost > unnoticeable on normal use. Sure, when running a fully encrypted system > and testing another installation inside VMware which is also encrypting > the disk it things start to get a little sluggish ;) > > Anyway, it would be very very nice to finally have fs encryption directly > supported in FC. Just so there's no confusion: I'm all for it being supported. I'm just not for it being the default. -sv From skvidal at linux.duke.edu Fri Mar 24 19:54:39 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Fri, 24 Mar 2006 14:54:39 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <8086.192.54.193.25.1143190966.squirrel@rousalka.dyndns.org> References: <4422B137.6010000@redhat.com> <1143140732.32685.3.camel@cutter> <8086.192.54.193.25.1143190966.squirrel@rousalka.dyndns.org> Message-ID: <1143230079.4336.47.camel@cutter> On Fri, 2006-03-24 at 10:02 +0100, Nicolas Mailhot wrote: > Le Jeu 23 mars 2006 20:05, seth vidal a ?crit : > > > if I were in the same position I would, of course, use encrypted file > > systems - but to have that overhead for the default is a bit extreme. > > > > Sounds like the IT group in corporation needs to stop being so naive. > > What I find na?ve is continuing to believe security can be special-cased. > Do you think company users bother to report every single > security-sensitive documents they manipulate ? Do you think home users > think about it ? > > Either you do it for everyone and it has a chance to be in place when > it'll really be needed or you shouldn't bother at all. The kind of > bureaucracy that would be needed to identify exactly what bits needed to > be protected is just never going to happen. I think if we made it the default we'll end up with a lot of users unable to get into their data when a disk partially fails. -sv From jspaleta at gmail.com Fri Mar 24 19:59:43 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 24 Mar 2006 14:59:43 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <8086.192.54.193.25.1143190966.squirrel@rousalka.dyndns.org> References: <4422B137.6010000@redhat.com> <1143140732.32685.3.camel@cutter> <8086.192.54.193.25.1143190966.squirrel@rousalka.dyndns.org> Message-ID: <604aa7910603241159o5d28f219sa3ede76d5f2f00f6@mail.gmail.com> On 3/24/06, Nicolas Mailhot wrote: > What I find na?ve is continuing to believe security can be special-cased. > Do you think company users bother to report every single > security-sensitive documents they manipulate ? Do you think home users > think about it ? Is there an established home user oriented differential/incremental backup mechanism which can handle the complication of encypted filesystems? As a home users...with desktop systems.. I'm much more concerned about data integrity, recovery in case of a harddrive failure, and data archiving than I am about someone getting access to 99% of the information throughout my home directory. And no a dd of the whole filesystem to a different disk certainly doesn't count in my book as "home user oriented" and doesn't meet my other needs for transparency if the encyption is left in place. For my personal use I'd find it much more reasonable to have the option to encapsulate sensitive personal information from that of information I can transparently backup to make it easier to sort through the backup material when necessary. -jef From katzj at redhat.com Fri Mar 24 21:59:41 2006 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 24 Mar 2006 16:59:41 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <20060324165041.GB8291@petra.dvoda.cz> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> Message-ID: <1143237581.7616.16.camel@orodruin.boston.redhat.com> On Fri, 2006-03-24 at 17:50 +0100, Karel Zak wrote: > On Thu, Mar 23, 2006 at 09:31:19AM -0500, Daniel J Walsh wrote: > > Laptops have becoming the standard machine for people, replacing the > > desktop. We need to consider defaulting FC6 with encrypted filesystem > > or at least homedirs out of the box. This should be a key feature of FC6. > > I don't think that encrypted filesystem is a good way. I think better > idea is support for encrypted devices (partitions). It's solution > independent on filesystem and it's useful for swaps too. For more > details see cryptsetup-luks and dm-crypt. The problem is that encrypting block devices in a user-friendly fashion kind of sucks. * Encrypting the rootfs's block device sucks as you need to be able to get a passphrase or whatever at boot-time before you have X (... and thus can display the proper fonts) and before you have a sane keyboard map. * You don't want an encryption that's global across all of /home, you really want to encrypt each user's home directory separately so that they can access their own stuff without needing any sort of admin access. But you don't want to require a separate block device per user as this is an administration nightmare. For some cases (eg, swap, removable devices), block device level can make a lot of sense. But for things like home directories, it kind of sucks. :-/ Jeremy From davidz at redhat.com Sat Mar 25 01:49:16 2006 From: davidz at redhat.com (David Zeuthen) Date: Fri, 24 Mar 2006 20:49:16 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <20060324165041.GB8291@petra.dvoda.cz> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> Message-ID: <1143251356.13660.7.camel@daxter.boston.redhat.com> On Fri, 2006-03-24 at 17:50 +0100, Karel Zak wrote: > On Thu, Mar 23, 2006 at 09:31:19AM -0500, Daniel J Walsh wrote: > > Laptops have becoming the standard machine for people, replacing the > > desktop. We need to consider defaulting FC6 with encrypted filesystem > > or at least homedirs out of the box. This should be a key feature of FC6. > > I don't think that encrypted filesystem is a good way. I think better > idea is support for encrypted devices (partitions). Yea. > It's solution > independent on filesystem and it's useful for swaps too. For more > details see cryptsetup-luks and dm-crypt. We have full support for LUKS on removable / hotpluggable devices via HAL these days, see http://blog.fubar.dk/?p=64 - This stuff did make FC5 and it's integrated with gnome-keyring manager / gnome-vfs etc. (btw, for FC6 and GNOME 2.16 I hope to have a very simple formatting / partitioning tool for drives which will include setting up LUKS partitions - and it won't do silly things like requiring the root password (in the default install; will be configurable) for at least removable and hotpluggable media. Of course I can't promise to have this done for FC6 as I presently do most of this in my spare time...) David From blizzard at redhat.com Sat Mar 25 15:38:30 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Sat, 25 Mar 2006 10:38:30 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143251356.13660.7.camel@daxter.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> Message-ID: <442563F6.7010007@redhat.com> David Zeuthen wrote: > (btw, for FC6 and GNOME 2.16 I hope to have a very simple formatting / > partitioning tool for drives which will include setting up LUKS > partitions - and it won't do silly things like requiring the root > password (in the default install; will be configurable) for at least > removable and hotpluggable media. Of course I can't promise to have this > done for FC6 as I presently do most of this in my spare time...) Is there any chance that we can come up with something that doesn't require something that's block-level and requires repartitioning? The migration path pretty much sucks if we don't try for something else. Hmm. Can we do something like this when someone sets up an encrypted home directory: o Identify all the files that descend from that user's home directory o Identify all the blocks that are associated with those files o Encrypt those blocks The trick here is that every file below that tree also has to be encrypted over time. Maybe we could use some interesting mix of xattrs and kernel hooks when you open one of the xattributed files? Doesn't selinux have some hooks like this? (Everything below this directory has policy X...) --Chris From kzak at redhat.com Sat Mar 25 16:50:37 2006 From: kzak at redhat.com (Karel Zak) Date: Sat, 25 Mar 2006 17:50:37 +0100 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143237581.7616.16.camel@orodruin.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143237581.7616.16.camel@orodruin.boston.redhat.com> Message-ID: <20060325165037.GA27151@petra.dvoda.cz> On P?, b?e 24, 2006 at 04:59:41 -0500, Jeremy Katz wrote: > On Fri, 2006-03-24 at 17:50 +0100, Karel Zak wrote: > > On Thu, Mar 23, 2006 at 09:31:19AM -0500, Daniel J Walsh wrote: > > > Laptops have becoming the standard machine for people, replacing the > > > desktop. We need to consider defaulting FC6 with encrypted filesystem > > > or at least homedirs out of the box. This should be a key feature of FC6. > > > > I don't think that encrypted filesystem is a good way. I think better > > idea is support for encrypted devices (partitions). It's solution > > independent on filesystem and it's useful for swaps too. For more > > details see cryptsetup-luks and dm-crypt. > > The problem is that encrypting block devices in a user-friendly fashion > kind of sucks. I think the original post was about laptop users. > * Encrypting the rootfs's block device sucks as you need to be able to > get a passphrase or whatever at boot-time before you have X (... and > thus can display the proper fonts) and before you have a sane keyboard > map. > * You don't want an encryption that's global across all of /home, you > really want to encrypt each user's home directory separately so that > they can access their own stuff without needing any sort of admin Sorry, but privacy on system where someone other has root permissions is illusion only. I don't understand how could be really safe system where admin is able to modify kernel or some system util and steal your password (or private key or whatever). > access. But you don't want to require a separate block device per user > as this is an administration nightmare. > > For some cases (eg, swap, removable devices), block device level can > make a lot of sense. But for things like home directories, it kind of > sucks. :-/ Karel -- Karel Zak From alan at redhat.com Sat Mar 25 17:14:51 2006 From: alan at redhat.com (Alan Cox) Date: Sat, 25 Mar 2006 12:14:51 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143237581.7616.16.camel@orodruin.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143237581.7616.16.camel@orodruin.boston.redhat.com> Message-ID: <20060325171451.GF5869@devserv.devel.redhat.com> On Fri, Mar 24, 2006 at 04:59:41PM -0500, Jeremy Katz wrote: > * Encrypting the rootfs's block device sucks as you need to be able to > get a passphrase or whatever at boot-time before you have X (... and > thus can display the proper fonts) and before you have a sane keyboard > map. Thats only one problem. A Fedora or Red Hat root device is rather predictable and most people pick the same install sets so its 99% known plaintext for an attack From davidz at redhat.com Sat Mar 25 21:40:29 2006 From: davidz at redhat.com (David Zeuthen) Date: Sat, 25 Mar 2006 16:40:29 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <442563F6.7010007@redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> Message-ID: <1143322829.20575.23.camel@daxter.boston.redhat.com> On Sat, 2006-03-25 at 10:38 -0500, Christopher Blizzard wrote: > David Zeuthen wrote: > > (btw, for FC6 and GNOME 2.16 I hope to have a very simple formatting / > > partitioning tool for drives which will include setting up LUKS > > partitions - and it won't do silly things like requiring the root > > password (in the default install; will be configurable) for at least > > removable and hotpluggable media. Of course I can't promise to have this > > done for FC6 as I presently do most of this in my spare time...) > > Is there any chance that we can come up with something that doesn't > require something that's block-level and requires repartitioning? The > migration path pretty much sucks if we don't try for something else. I think Jeremy's point about using block level encryption on real disks for anything but removable / hotplugable devices makes sense. I also don't think we want to encrypt the entire home directory, that would suck for e.g. compiles of software Filevault on Mac OS X is also interesting http://www.apple.com/macosx/features/filevault/ So.. I've been toying with the idea of just using a loopback mount on $HOME/Documents; - The crypto bits are just store in $HOME/.encrypted-documents-image - Loopback mount said file on /dev/loop5 (or whatever) - when logging in, setup crypto using cryptsetup so the clear image is /dev/mapper/foo - if there is no fs on /dev/mapper/foo (/sbin/volume_id can tell us) format /dev/mapper/foo to be an ext3 file system - Mount /dev/mapper/foo at $HOME/Documents on login - Teach the file chooser / Nautilus about it - emblems - patch file chooser to warn if saving outside $HOME/Documents, maybe apps can set a property on the FileChooser object to disable this warning - Might want to move and symlink .gconf, .gnome2, .gnome2_private, whatever into $HOME/Documents Issues - Will probably require a system-level D-BUS service to do the heavy lifting; that's fine; D-BUS is the way to allow privileged operations to desktop processes in a secure way. And with the glib bindings it's not too difficult to do... - Not sure how to make the image grow when running out of space; maybe that requires some kernel bits; kernel guys? - Issues on NFS / shared homedir - but this is true on any attempt to do encrypted homedir - Issues with data migration if user already has something in $HOME/Documents - maybe just move it to the new encrypted target - Clearly this (and any attempt to do encrypted home directories) needs Single Sign On so we can recover the encryption key easily when the user authorizes as part of the login process - it's equivalent to our desire of unlocking the GNOME keyring, see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=125682 for details. It's all about trade-off's I think ; I'm not sure we can please everyone but I think this is a good compromise. So.. if you are crazy you may even use the same technique of of loopback mounting the image on $HOME but I don't think it's acceptable to encrypt the entire home directory. Or maybe it is... It really depends on what we want to do... Maybe some user interaction guys like clarkbw or seth should sit down and work out what user experience we want before we discuss technical implementation details... Anyho.. before we can do anything we also need to solve bug #125682.. I think many people will agree with me that it's annoying enough as is with having to manually unlock the keyring everytime one wants to use VPN or mount encrypted removable storage :-) David From triad at df.lth.se Sat Mar 25 22:58:22 2006 From: triad at df.lth.se (Linus Walleij) Date: Sat, 25 Mar 2006 23:58:22 +0100 (CET) Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143215588.4912.3.camel@localhost.localdomain> References: <4422B137.6010000@redhat.com> <1143215588.4912.3.camel@localhost.localdomain> Message-ID: On Fri, 24 Mar 2006, Paul W. Frields wrote: > As long as there's a clear visible option to do away with encryption on > the FS, that's cool. Deciding to put important data in a possibly > unretrievable state in the event of a user departure from a company or > an untimely demise is not a great idea without a plan to recover it. My > laptop is owned by my company, and I am sure they don't want me > encrypting data on it in a manner which prevents them from accessing it > should they wish to. The key is a key infrastructure, e.g. your device is encrypted so that you can access it with two keys: your key or a master key deployed at your company (this could be device-unique or just a big master key). I don't know if there are such things designed for LUKS tho... Linus Walleij From bressers at redhat.com Sun Mar 26 02:06:40 2006 From: bressers at redhat.com (Josh Bressers) Date: Sat, 25 Mar 2006 21:06:40 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: Your message of "Sat, 25 Mar 2006 16:40:29 EST." <1143322829.20575.23.camel@daxter.boston.redhat.com> Message-ID: <200603260206.k2Q26eXT012296@devserv.devel.redhat.com> > > > > Is there any chance that we can come up with something that doesn't > > require something that's block-level and requires repartitioning? The > > migration path pretty much sucks if we don't try for something else. > > I think Jeremy's point about using block level encryption on real disks > for anything but removable / hotplugable devices makes sense. I also > don't think we want to encrypt the entire home directory, that would > suck for e.g. compiles of software I'm somewhat surprised nobody has mentioned encfs yet. http://arg0.net/wiki/encfs I store many things in encfs filesystems as it's rather transparent and very easy to setup and use. I imagine with very little effort support could be built into nautilus. It's already in extras as fuse-encfs. The basics are that I have one directory named ~/.encfs, which has all the encrypted bits. I then "mount" the .encfs directory into ~/encfs, where I can see things as normal files (these are arbitrary names chosen by me, any name can be used). Here's a directory listing of ~/.encfs: % ls ~/.encfs 1k2A8hy,ELen4,JmfcH-51JG R8Xs0R097CPJJoc1bG2ZzXqX y6bOnGgyYiXmKAPav7giQaS, hxc7gEQKqRa,G1 TMej1GDE,weeNiUM0XYeC6Wv Everything in that directory is utter nonsense, but the magic part is, I can rsync my encrypted directory without ill effect. This lets me backup my encrypted information without needing the key (something lacking from many encrypted filesystems. -- JB From jspaleta at gmail.com Sun Mar 26 02:51:10 2006 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 25 Mar 2006 21:51:10 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <200603260206.k2Q26eXT012296@devserv.devel.redhat.com> References: <1143322829.20575.23.camel@daxter.boston.redhat.com> <200603260206.k2Q26eXT012296@devserv.devel.redhat.com> Message-ID: <604aa7910603251851o3850e03boe21f441d070b1d29@mail.gmail.com> On 3/25/06, Josh Bressers wrote: > Everything in that directory is utter nonsense, but the magic part is, I > can rsync my encrypted directory without ill effect. This lets me backup > my encrypted information without needing the key (something lacking from > many encrypted filesystems. Excellent... this is exactly the sort of backup functionality I need. This should work fine with my rdiff-backup scenario. I should make some time to play with this on my lan. -jef From fedora at camperquake.de Sun Mar 26 11:15:30 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 26 Mar 2006 13:15:30 +0200 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143215588.4912.3.camel@localhost.localdomain> References: <4422B137.6010000@redhat.com> <1143215588.4912.3.camel@localhost.localdomain> Message-ID: <20060326131530.553e7ffb@lain> Hi. On Fri, 24 Mar 2006 10:53:07 -0500, Paul W. Frields wrote > My laptop is owned by my company, and I am sure they don't want me > encrypting data on it in a manner which prevents them from accessing > it should they wish to. This is basically a question of policy, and not of the underyling technology. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Mar 27 08:31:18 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 27 Mar 2006 10:31:18 +0200 Subject: SSH key change on cvs.fedora.redhat.com? Message-ID: <20060327103118.4af1b576@python2> Hi, I just tried to update some CVS modules from the Extras CVS, and got a big fat warning about the ssh key which has changed. I haven't seen any mention of this this on this list. Is it to be expected? Feared? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5 Load : 0.27 0.48 0.37 From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Mon Mar 27 08:33:52 2006 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Mon, 27 Mar 2006 10:33:52 +0200 Subject: SSH key change on cvs.fedora.redhat.com? In-Reply-To: <20060327103118.4af1b576@python2> References: <20060327103118.4af1b576@python2> Message-ID: <20060327103352.61351e02@python2> Matthias Saou wrote : > I just tried to update some CVS modules from the Extras CVS, and got a big > fat warning about the ssh key which has changed. I haven't seen any > mention of this this on this list. Is it to be expected? Feared? FYI, and after reading the Extras list, the CVS system has been migrated to another host for which the the correct key is indeed : dd:0d:f1:d6:e2:f6:39:cf:ca:6b:03:28:8d:84:3a:d5. Definitely worth mentioning on this list too, though ;-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 5 (Bordeaux) - Linux kernel 2.6.16-1.2069_FC5 Load : 0.26 0.47 0.39 From fedora at camperquake.de Mon Mar 27 09:42:16 2006 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 27 Mar 2006 11:42:16 +0200 Subject: SSH key change on cvs.fedora.redhat.com? In-Reply-To: <20060327103352.61351e02@python2> References: <20060327103118.4af1b576@python2> <20060327103352.61351e02@python2> Message-ID: <20060327114216.68b76681@soran.addix.net> Hi. On Mon, 27 Mar 2006 10:33:52 +0200, Matthias Saou wrote: > FYI, and after reading the Extras list, the CVS system has been > migrated to another host for which the the correct key is indeed : > dd:0d:f1:d6:e2:f6:39:cf:ca:6b:03:28:8d:84:3a:d5. > > Definitely worth mentioning on this list too, though ;-) It's not exactly difficult to migrate SSH keys. What was the reason for the change? From skvidal at linux.duke.edu Mon Mar 27 11:41:01 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Mar 2006 06:41:01 -0500 Subject: SSH key change on cvs.fedora.redhat.com? In-Reply-To: <20060327114216.68b76681@soran.addix.net> References: <20060327103118.4af1b576@python2> <20060327103352.61351e02@python2> <20060327114216.68b76681@soran.addix.net> Message-ID: <1143459662.20913.42.camel@cutter> On Mon, 2006-03-27 at 11:42 +0200, Ralf Ertzinger wrote: > Hi. > > On Mon, 27 Mar 2006 10:33:52 +0200, Matthias Saou wrote: > > > FYI, and after reading the Extras list, the CVS system has been > > migrated to another host for which the the correct key is indeed : > > dd:0d:f1:d6:e2:f6:39:cf:ca:6b:03:28:8d:84:3a:d5. > > > > Definitely worth mentioning on this list too, though ;-) > > It's not exactly difficult to migrate SSH keys. What was the reason > for the change? +1 -sv From katzj at redhat.com Mon Mar 27 16:33:33 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Mar 2006 11:33:33 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <20060325165037.GA27151@petra.dvoda.cz> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143237581.7616.16.camel@orodruin.boston.redhat.com> <20060325165037.GA27151@petra.dvoda.cz> Message-ID: <1143477213.4785.45.camel@orodruin.boston.redhat.com> On Sat, 2006-03-25 at 17:50 +0100, Karel Zak wrote: > On P?, b?e 24, 2006 at 04:59:41 -0500, Jeremy Katz wrote: > > On Fri, 2006-03-24 at 17:50 +0100, Karel Zak wrote: > > > On Thu, Mar 23, 2006 at 09:31:19AM -0500, Daniel J Walsh wrote: > > > > Laptops have becoming the standard machine for people, replacing the > > > > desktop. We need to consider defaulting FC6 with encrypted filesystem > > > > or at least homedirs out of the box. This should be a key feature of FC6. > > > > > > I don't think that encrypted filesystem is a good way. I think better > > > idea is support for encrypted devices (partitions). It's solution > > > independent on filesystem and it's useful for swaps too. For more > > > details see cryptsetup-luks and dm-crypt. > > > > The problem is that encrypting block devices in a user-friendly fashion > > kind of sucks. > > I think the original post was about laptop users. So because the computer is smaller and I carry it with me, the user interface problems go away? I don't buy it :) > > * You don't want an encryption that's global across all of /home, you > > really want to encrypt each user's home directory separately so that > > they can access their own stuff without needing any sort of admin > > Sorry, but privacy on system where someone other has root permissions > is illusion only. I don't understand how could be really safe system > where admin is able to modify kernel or some system util and steal > your password (or private key or whatever). No, I'm saying that Bob shouldn't need an administrator to unlock the /home on his laptop. But Bob and Jim should be able to both have accounts (or maybe it's Bob and his girlfriend) Jeremy From blizzard at redhat.com Mon Mar 27 18:46:01 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Mar 2006 13:46:01 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143477213.4785.45.camel@orodruin.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143237581.7616.16.camel@orodruin.boston.redhat.com> <20060325165037.GA27151@petra.dvoda.cz> <1143477213.4785.45.camel@orodruin.boston.redhat.com> Message-ID: <442832E9.40306@redhat.com> Jeremy Katz wrote: >>> * You don't want an encryption that's global across all of /home, you >>> really want to encrypt each user's home directory separately so that >>> they can access their own stuff without needing any sort of admin >> Sorry, but privacy on system where someone other has root permissions >> is illusion only. I don't understand how could be really safe system >> where admin is able to modify kernel or some system util and steal >> your password (or private key or whatever). > > No, I'm saying that Bob shouldn't need an administrator to unlock > the /home on his laptop. But Bob and Jim should be able to both have > accounts (or maybe it's Bob and his girlfriend) So based on the current way that the we do encryption (block-level for an entire parition?) sucks because it doesn't allow this kind of thing? Sounds like we have some work to do to make it really useful. --Chris From blizzard at redhat.com Mon Mar 27 20:56:54 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Mar 2006 15:56:54 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143322829.20575.23.camel@daxter.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> Message-ID: <44285196.7090208@redhat.com> David Zeuthen wrote: > > I think Jeremy's point about using block level encryption on real disks > for anything but removable / hotplugable devices makes sense. I also > don't think we want to encrypt the entire home directory, that would > suck for e.g. compiles of software Do most people do compiling? Or heavy-duty I/O for that matter? I think that if we would right click and just say "disable encryption on this directory" that would be enough. --Chris From blizzard at redhat.com Mon Mar 27 20:58:40 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Mar 2006 15:58:40 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: References: <4422B137.6010000@redhat.com> <1143215588.4912.3.camel@localhost.localdomain> Message-ID: <44285200.2010804@redhat.com> Linus Walleij wrote: > The key is a key infrastructure, e.g. your device is encrypted so that > you can access it with two keys: your key or a master key deployed at > your company (this could be device-unique or just a big master key). > > I don't know if there are such things designed for LUKS tho... > Agreed on this point. Key recovery is a big problem and one that it takes a lot of infrastructure to support. Red Hat has some products in this area, but they aren't open source (yet.) But it's probably waaaay too much for someone who just wants to download and try fedora. I would suggest that designing so that it uses the right kinds of keys and what you want the user experience to be is the right place to start. And then figure out how to build management infrastructure from there. --Chris From katzj at redhat.com Mon Mar 27 21:02:19 2006 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 27 Mar 2006 16:02:19 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <44285196.7090208@redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> Message-ID: <1143493340.4785.82.camel@orodruin.boston.redhat.com> On Mon, 2006-03-27 at 15:56 -0500, Christopher Blizzard wrote: > David Zeuthen wrote: > > I think Jeremy's point about using block level encryption on real disks > > for anything but removable / hotplugable devices makes sense. I also > > don't think we want to encrypt the entire home directory, that would > > suck for e.g. compiles of software > > Do most people do compiling? Or heavy-duty I/O for that matter? I > think that if we would right click and just say "disable encryption on > this directory" that would be enough. *nod* You'll also want to disable for, eg, ~/public_html so that apache can actually show stuff that you're trying to show (or gnome-user-share or whatever) Jeremy From blizzard at redhat.com Mon Mar 27 21:05:51 2006 From: blizzard at redhat.com (Christopher Blizzard) Date: Mon, 27 Mar 2006 16:05:51 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143493340.4785.82.camel@orodruin.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> Message-ID: <442853AF.7010800@redhat.com> Jeremy Katz wrote: > On Mon, 2006-03-27 at 15:56 -0500, Christopher Blizzard wrote: >> David Zeuthen wrote: >>> I think Jeremy's point about using block level encryption on real disks >>> for anything but removable / hotplugable devices makes sense. I also >>> don't think we want to encrypt the entire home directory, that would >>> suck for e.g. compiles of software >> Do most people do compiling? Or heavy-duty I/O for that matter? I >> think that if we would right click and just say "disable encryption on >> this directory" that would be enough. > > *nod* You'll also want to disable for, eg, ~/public_html so that apache > can actually show stuff that you're trying to show (or gnome-user-share > or whatever) > I think that that particular apache runs with the same UID as you do. :) blizzard 2153 0.0 0.1 8364 624 ? Ss Mar25 0:00 /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user.conf -C Listen 60258 --Chris From skvidal at linux.duke.edu Tue Mar 28 00:14:16 2006 From: skvidal at linux.duke.edu (seth vidal) Date: Mon, 27 Mar 2006 19:14:16 -0500 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <442853AF.7010800@redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> Message-ID: <1143504856.20913.65.camel@cutter> > I think that that particular apache runs with the same UID as you do. :) > > blizzard 2153 0.0 0.1 8364 624 ? Ss Mar25 0:00 > /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user.conf -C Listen 60258 > for gnome-user-share, yes. for a webserver exporting ~user, no it doesn't -sv From smooge at gmail.com Tue Mar 28 00:53:06 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 27 Mar 2006 17:53:06 -0700 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <1143215588.4912.3.camel@localhost.localdomain> References: <4422B137.6010000@redhat.com> <1143215588.4912.3.camel@localhost.localdomain> Message-ID: <80d7e4090603271653o6557cba2y32177ca5c9d9b099@mail.gmail.com> On 3/24/06, Paul W. Frields wrote: > On Thu, 2006-03-23 at 09:31 -0500, Daniel J Walsh wrote: > > Received an FedEX from Fidelity this morning seems, one of their > > laptops was stolen. On the laptop, was the Personal information, > > including Social Security number, of everyone in the HP Retirement > > plan (I suppose this includes DEC/Compaq and HP. They have us jumping > > through hoops and going to Credit Agencies to watch for unusual activity. > > Now if the system had been encrypted ... Now why was this data on a > > laptop? I don't know. > > > > Laptops have becoming the standard machine for people, replacing the > > desktop. We need to consider defaulting FC6 with encrypted filesystem > > or at least homedirs out of the box. This should be a key feature of FC6. > > As long as there's a clear visible option to do away with encryption on > the FS, that's cool. Deciding to put important data in a possibly > unretrievable state in the event of a user departure from a company or > an untimely demise is not a great idea without a plan to recover it. My > laptop is owned by my company, and I am sure they don't want me > encrypting data on it in a manner which prevents them from accessing it > should they wish to. The solution I have seen with this is corporate key management. This means that every unit that is encrypted is encrypted so that the corporate secret key or the users key can decrypt the file. On our systems we are supposed to use Entrust for this key management . On the windows side you can create an entrust folder that you drop your documents to and also tell the wellbehaved applications (ha) to use as their tempspace /save space. -- Stephen J Smoogen. CSIRT/Linux System Administrator From davidz at redhat.com Tue Mar 28 00:54:00 2006 From: davidz at redhat.com (David Zeuthen) Date: Mon, 27 Mar 2006 19:54:00 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <442853AF.7010800@redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> Message-ID: <1143507240.5625.12.camel@daxter.boston.redhat.com> On Mon, 2006-03-27 at 16:05 -0500, Christopher Blizzard wrote: > blizzard 2153 0.0 0.1 8364 624 ? Ss Mar25 0:00 > /usr/sbin/httpd -f /usr/share/gnome-user-share/dav_user.conf -C Listen 60258 Yea, gnome-user-share is great; I use it a lot, every day actually. However, when I started using it I found that I had to turn off the firewall since it listens on an arbitrary high port in the desktop session.. Did this ever get fixed, ie. do we punch holes in the firewall as appropriate? Similar, does Rhythmbox and Banshee punch holes for their sharing services? Or do we still say "disable the firewall and know what you are doing". IIRC there were similar issues with SMB browsing and alexl did a netfilter kernel module to work around this around the FC3 / RHEL4 time-frame; not sure it's that easy for g-u-s and the media players. David From smooge at gmail.com Tue Mar 28 00:57:46 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Mon, 27 Mar 2006 17:57:46 -0700 Subject: Isn't it time for the encrypted file system??? In-Reply-To: <200603260206.k2Q26eXT012296@devserv.devel.redhat.com> References: <1143322829.20575.23.camel@daxter.boston.redhat.com> <200603260206.k2Q26eXT012296@devserv.devel.redhat.com> Message-ID: <80d7e4090603271657j63b2115fma3319de78d288c6e@mail.gmail.com> On 3/25/06, Josh Bressers wrote: > > > > > > Is there any chance that we can come up with something that doesn't > > > require something that's block-level and requires repartitioning? The > > > migration path pretty much sucks if we don't try for something else. > > > > I think Jeremy's point about using block level encryption on real disks > > for anything but removable / hotplugable devices makes sense. I also > > don't think we want to encrypt the entire home directory, that would > > suck for e.g. compiles of software > > I'm somewhat surprised nobody has mentioned encfs yet. > http://arg0.net/wiki/encfs > > I store many things in encfs filesystems as it's rather transparent and > very easy to setup and use. I imagine with very little effort support > could be built into nautilus. > > It's already in extras as fuse-encfs. > > The basics are that I have one directory named ~/.encfs, which has all the > encrypted bits. I then "mount" the .encfs directory into ~/encfs, where I > can see things as normal files (these are arbitrary names chosen by me, any > name can be used). Here's a directory listing of ~/.encfs: > So what is needed extra is a nautilus-fuse-encfs that puts a nice little safe/vault on your desktop... and some sort of routines to make sure that various desktop programs know to save their temporary data to the encfs.. what to do about swap and mis-behaving programs I do not know. -- Stephen J Smoogen. CSIRT/Linux System Administrator From alexl at redhat.com Tue Mar 28 07:51:29 2006 From: alexl at redhat.com (Alexander Larsson) Date: Tue, 28 Mar 2006 09:51:29 +0200 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143507240.5625.12.camel@daxter.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> Message-ID: <1143532289.29890.145.camel@greebo> On Mon, 2006-03-27 at 19:54 -0500, David Zeuthen wrote: > IIRC there were similar issues with SMB browsing and alexl did a > netfilter kernel module to work around this around the FC3 / RHEL4 > time-frame; not sure it's that easy for g-u-s and the media players. That was not the same sort of issue. The SMB browse issue was, we send a UDP multicast packet, and the reply gets filtered because the firewall doesn't understand the returned packet is a reply. This was fixed by writing a special connection tracker for such traffic. The problem with g-u-s is that this really is a server that other people connect to, which is exactly the kind of thing we enable the firewall to prevent. I must say I'm slightly bothered by the "lets have the apps punch holes in the firewall" approach. If any app can open holes in the firewall, what use is the firewall then? It will only be protecting ports that no application is listening too. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a short-sighted amnesiac filmmaker from a doomed world. She's a supernatural hip-hop safe cracker fleeing from a Satanic cult. They fight crime! From pmatilai at laiskiainen.org Tue Mar 28 08:13:16 2006 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 28 Mar 2006 00:13:16 -0800 (PST) Subject: Isn't it time for the encrypted file system??? In-Reply-To: <44285196.7090208@redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> Message-ID: On Mon, 27 Mar 2006, Christopher Blizzard wrote: > David Zeuthen wrote: >> >> I think Jeremy's point about using block level encryption on real disks >> for anything but removable / hotplugable devices makes sense. I also >> don't think we want to encrypt the entire home directory, that would >> suck for e.g. compiles of software > > Do most people do compiling? Or heavy-duty I/O for that matter? I think > that if we would right click and just say "disable encryption on this > directory" that would be enough. That might be fine for a home user but in a corporate environment the user does not necessarily get to say something should not be encrypted "because it's inconvenient and slows down my builds". If it were up to the users, I'm pretty sure *nobody* here (where I work) would bother encrypting their systems at all simpy because it's so much more convient not to. - Panu - From alan at redhat.com Tue Mar 28 10:35:13 2006 From: alan at redhat.com (Alan Cox) Date: Tue, 28 Mar 2006 05:35:13 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143532289.29890.145.camel@greebo> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> Message-ID: <20060328103513.GG12588@devserv.devel.redhat.com> On Tue, Mar 28, 2006 at 09:51:29AM +0200, Alexander Larsson wrote: > I must say I'm slightly bothered by the "lets have the apps punch holes > in the firewall" approach. If any app can open holes in the firewall, > what use is the firewall then? It will only be protecting ports that no > application is listening too. The proposal I made (umm dig, dig deep through archives 4 years ago) was that the firewall tool has an interface allowing applications to add holes and to deal with holes but that the config tool for the app would always ask when it seemed relevant eg You have just enabled network printing Currently your firewall only permits local access for printing Would you like to configure the firewall to allow network printer access Allow All Customize Deny All And also use the same hooks so that rpm -e deinstalls the firewall hole and closes it. Punching holes in general otherwise is dangerous. From davidz at redhat.com Tue Mar 28 15:54:16 2006 From: davidz at redhat.com (David Zeuthen) Date: Tue, 28 Mar 2006 10:54:16 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143532289.29890.145.camel@greebo> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> Message-ID: <1143561256.4677.17.camel@daxter.boston.redhat.com> On Tue, 2006-03-28 at 09:51 +0200, Alexander Larsson wrote: > I must say I'm slightly bothered by the "lets have the apps punch holes > in the firewall" approach. If any app can open holes in the firewall, > what use is the firewall then? It will only be protecting ports that no > application is listening too. Sure, of course, we need auth from the user (ask them to put in their own password or the root password [1]) to open the hole as Alan says. Just allowing any app to open arbitrary ports would be a security hole. We might need some fixes both kernel- and g-u-s-side too to make this work in a secure way; e.g. reuse same port number next time; only allow /usr/bin/httpd to bind to that port etc etc I must say.. I'm slightly annoyed by the fact that we put in a feature like g-u-s and just don't fix this and expect the user to Google his way out of this. We already know that the only way to fix this right now is to turn off the firewall. Not very cool. Can someone please look at this for FC6? And at the same time make sure the Banshee and Rhythmbox's of the world can use this feature too? Maybe even push an API David [1] : the PolicyKit stuff I'm working on will make this much easier though it will require the firewall to export a system-level service to allow punching holes... > > =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > Alexander Larsson Red Hat, Inc > alexl at redhat.com alla at lysator.liu.se > He's a short-sighted amnesiac filmmaker from a doomed world. She's a > supernatural hip-hop safe cracker fleeing from a Satanic cult. They fight > crime! > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers From dwalsh at redhat.com Tue Mar 28 16:02:05 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 28 Mar 2006 11:02:05 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143561256.4677.17.camel@daxter.boston.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> Message-ID: <44295DFD.6060805@redhat.com> David Zeuthen wrote: > On Tue, 2006-03-28 at 09:51 +0200, Alexander Larsson wrote: > >> I must say I'm slightly bothered by the "lets have the apps punch holes >> in the firewall" approach. If any app can open holes in the firewall, >> what use is the firewall then? It will only be protecting ports that no >> application is listening too. >> > > Sure, of course, we need auth from the user (ask them to put in their > own password or the root password [1]) to open the hole as Alan says. > Just allowing any app to open arbitrary ports would be a security hole. > > We might need some fixes both kernel- and g-u-s-side too to make this > work in a secure way; e.g. reuse same port number next time; only > allow /usr/bin/httpd to bind to that port etc etc > > I must say.. I'm slightly annoyed by the fact that we put in a feature > like g-u-s and just don't fix this and expect the user to Google his way > out of this. We already know that the only way to fix this right now is > to turn off the firewall. Not very cool. > > Can someone please look at this for FC6? And at the same time make sure > the Banshee and Rhythmbox's of the world can use this feature too? Maybe > even push an API > > David > > [1] : the PolicyKit stuff I'm working on will make this much easier > though it will require the firewall to export a system-level service to > allow punching holes... > > Should also be wrapped in SELinux to make sure some random app does not ask for this. If I am a user and NetworkManager pops a window saying somethine like "In order to run correctly I need your computer to turn purple, and run the Hypervizor at Warp 3" I am going to answer the question, "Yes" So only apps with a security policy should even be able to do this. > >> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= >> Alexander Larsson Red Hat, Inc >> alexl at redhat.com alla at lysator.liu.se >> He's a short-sighted amnesiac filmmaker from a doomed world. She's a >> supernatural hip-hop safe cracker fleeing from a Satanic cult. They fight >> crime! >> >> -- >> Fedora-maintainers mailing list >> Fedora-maintainers at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-maintainers >> > > -- > Fedora-maintainers mailing list > Fedora-maintainers at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-maintainers > From orion at cora.nwra.com Tue Mar 28 17:23:11 2006 From: orion at cora.nwra.com (Orion Poplawski) Date: Tue, 28 Mar 2006 10:23:11 -0700 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060328103513.GG12588@devserv.devel.redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <20060328103513.GG12588@devserv.devel.redhat.com> Message-ID: <442970FF.3010205@cora.nwra.com> Alan Cox wrote: > > eg > > You have just enabled network printing > Currently your firewall only permits local > access for printing > > Would you like to configure the firewall > to allow network printer access > > Allow All Customize Deny All I was just doing this with yast on SuSE and it did basically exactly that. -- Orion Poplawski System Administrator 303-415-9701 x222 Colorado Research Associates/NWRA FAX: 303-415-9702 3380 Mitchell Lane, Boulder CO 80301 http://www.co-ra.com From davidz at redhat.com Tue Mar 28 17:56:12 2006 From: davidz at redhat.com (David Zeuthen) Date: Tue, 28 Mar 2006 12:56:12 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <44295DFD.6060805@redhat.com> References: <4422B137.6010000@redhat.com> <20060324165041.GB8291@petra.dvoda.cz> <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> Message-ID: <1143568573.4677.42.camel@daxter.boston.redhat.com> On Tue, 2006-03-28 at 11:02 -0500, Daniel J Walsh wrote: > Should also be wrapped in SELinux to make sure some random app does not > ask for this. If I am a user and NetworkManager pops a window saying > somethine like > "In order to run correctly I need your computer to turn purple, and run > the Hypervizor at Warp 3" I am going to answer the question, "Yes" > > So only apps with a security policy should even be able to do this. And, I might add, this would be a another perfect showcase of why SELinux is important on the desktop. Btw, with the PolicyKit bits I'm writing it will be easy to do this even without user interaction other than turning g-u-s on; basically it goes like this 1. label /usr/libexec/gnome-user-share with a label so it runs in a well-known and specific security domain 2. write a small system-level daemon for punching holes in the firewall and start it on boot up (when we get activation on the D-BUS system message bus we don't even need to start it on boot up) 3. g-u-s starts; pokes system-level daemon for punching a hole via D-BUS 4. system-level daemon checks security domain; rejects anything but the domain we labeled /usr/libexec/gnome-user-share with; if OK punches a hole in the firewall and reconfigures SELinux on the fly so /usr/sbin/httpd is allowed to listen to the given port. 5. if rejected, g-u-s brings up a dialog asking for privileges; either the users own password or the super user password (this is a feature of PolicyKit); probably only wants this when starting from the "Personal File Sharing" capplet, e.g. not on login So this should be trivial once PolicyKit is finished. Specifically the system-level helper for punching holes in the firewall would be distributed with g-u-s. In fact, when PolicyKit is ready for this, I'm going to try to write this patch for g-u-s... it shouldn't take more than a day or two.. Btw, this should be upstream friendly too; the fact that we're using SELinux just means we don't need the user to auth when starting g-u-s. David From mattdm at mattdm.org Wed Mar 29 00:33:59 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 28 Mar 2006 19:33:59 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <44295DFD.6060805@redhat.com> References: <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> Message-ID: <20060329003359.GA16063@jadzia.bu.edu> On Tue, Mar 28, 2006 at 11:02:05AM -0500, Daniel J Walsh wrote: > Should also be wrapped in SELinux to make sure some random app does not > ask for this. If I am a user and NetworkManager pops a window saying > somethine like > "In order to run correctly I need your computer to turn purple, and run > the Hypervizor at Warp 3" I am going to answer the question, "Yes" > So only apps with a security policy should even be able to do this. What would happen in the absence of SELinux? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From dwalsh at redhat.com Wed Mar 29 05:56:46 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Mar 2006 00:56:46 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060329003359.GA16063@jadzia.bu.edu> References: <1143251356.13660.7.camel@daxter.boston.redhat.com> <442563F6.7010007@redhat.com> <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> Message-ID: <442A219E.80404@redhat.com> Matthew Miller wrote: > On Tue, Mar 28, 2006 at 11:02:05AM -0500, Daniel J Walsh wrote: > >> Should also be wrapped in SELinux to make sure some random app does not >> ask for this. If I am a user and NetworkManager pops a window saying >> somethine like >> "In order to run correctly I need your computer to turn purple, and run >> the Hypervizor at Warp 3" I am going to answer the question, "Yes" >> So only apps with a security policy should even be able to do this. >> > > What would happen in the absence of SELinux? > It will ask the user and the user will say yes. In the SELinux case it will still ask the user, but only an approved app will be able to open the whole in the firewall. From tmraz at redhat.com Wed Mar 29 09:02:25 2006 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 29 Mar 2006 11:02:25 +0200 Subject: File upload doesn't work Message-ID: <1143622945.3838.19.camel@perun.kabelta.loc> The subject says it all. make new-source FILES=openoffice.org-dict-cs_CZ.tar.gz Checking : openoffice.org-dict-cs_CZ.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... ERROR: could not check remote file status make: *** [new-source] Error 255 curl: (22) The requested URL returned error: 500 -- Tomas Mraz From sopwith at redhat.com Wed Mar 29 18:28:10 2006 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 29 Mar 2006 13:28:10 -0500 (EST) Subject: File upload doesn't work In-Reply-To: <1143622945.3838.19.camel@perun.kabelta.loc> References: <1143622945.3838.19.camel@perun.kabelta.loc> Message-ID: On Wed, 29 Mar 2006, Tomas Mraz wrote: > The subject says it all. > > make new-source FILES=openoffice.org-dict-cs_CZ.tar.gz > > Checking : openoffice.org-dict-cs_CZ.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-source] Error 255 > > curl: (22) The requested URL returned error: 500 So for some reason /etc/resolv.conf was not world-readable. Please try again. Best, -- Elliot From gemi at bluewin.ch Wed Mar 29 18:40:23 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 29 Mar 2006 20:40:23 +0200 Subject: File upload doesn't work In-Reply-To: References: <1143622945.3838.19.camel@perun.kabelta.loc> Message-ID: <1143657623.14504.0.camel@scriabin.tannenrauch.ch> On Wed, 2006-03-29 at 13:28 -0500, Elliot Lee wrote: > he requested URL returned error: 500 > > So for some reason /etc/resolv.conf was not world-readable. Please try > again. > > Best, > -- Elliot Ok, works now. Thanks -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From gemi at bluewin.ch Wed Mar 29 18:46:19 2006 From: gemi at bluewin.ch (=?ISO-8859-1?Q?G=E9rard?= Milmeister) Date: Wed, 29 Mar 2006 20:46:19 +0200 Subject: File upload doesn't work In-Reply-To: <1143657623.14504.0.camel@scriabin.tannenrauch.ch> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> Message-ID: <1143657979.14815.1.camel@scriabin.tannenrauch.ch> On Wed, 2006-03-29 at 20:40 +0200, G?rard Milmeister wrote: > On Wed, 2006-03-29 at 13:28 -0500, Elliot Lee wrote: > > he requested URL returned error: 500 > > > > So for some reason /etc/resolv.conf was not world-readable. Please try > > again. > > > > Best, > > -- Elliot > Ok, works now. However when building: Downloading sweep-0.9.1.tar.bz2... --13:44:34-- http://cvs.fedora.redhat.com/repo/extras/sweep/sweep-0.9.1.tar.bz2/7c346e28ff09c4a4f529a607ffd165f9/sweep-0.9.1.tar.bz2 => `sweep-0.9.1.tar.bz2' Resolving cvs.fedora.redhat.com... 209.132.176.51 Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. HTTP request sent, awaiting response... 404 Not Found 13:44:34 ERROR 404: Not Found. FINISHED --13:44:34-- Downloaded: 0 bytes in 0 files Could not download source file: sweep-0.9.1.tar.bz2 does not exist -- G?rard Milmeister Langackerstrasse 49 CH-8057 Z?rich From nicolas.mailhot at laposte.net Wed Mar 29 19:44:22 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 29 Mar 2006 21:44:22 +0200 Subject: File upload doesn't work In-Reply-To: <1143658020.8872.1.camel@localhost.localdomain> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> <1143658020.8872.1.camel@localhost.localdomain> Message-ID: <1143661465.2562.5.camel@rousalka.dyndns.org> Le mercredi 29 mars 2006 ? 20:47 +0200, Joost Soeterbroek a ?crit : > Ok, file upload works now, but then there is the next bottleneck with > the plague build server not being able to find the source tarball: Error: could not make srpm for dejavu-fonts-2_4_1-1_fc4 - output was: Downloading dejavu-sfd-2.4.1.tar.gz... --14:37:42-- http://cvs.fedora.redhat.com/repo/extras/dejavu-fonts/dejavu-sfd-2.4.1.tar.gz/ea7ee1cd16880a8ce5b3e70d97c41fc8/dejavu-sfd-2.4.1.tar.gz => `dejavu-sfd-2.4.1.tar.gz' Resolving cvs.fedora.redhat.com... 209.132.176.51 Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. HTTP request sent, awaiting response... 404 Not Found 14:37:42 ERROR 404: Not Found. FINISHED --14:37:42-- Downloaded: 0 bytes in 0 files Could not download source file: dejavu-sfd-2.4.1.tar.gz does not exist make: *** [dejavu-sfd-2.4.1.tar.gz] Error 1 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From chrisw at redhat.com Wed Mar 29 19:49:14 2006 From: chrisw at redhat.com (Chris Wright) Date: Wed, 29 Mar 2006 11:49:14 -0800 Subject: File upload doesn't work In-Reply-To: <1143657979.14815.1.camel@scriabin.tannenrauch.ch> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> <1143657979.14815.1.camel@scriabin.tannenrauch.ch> Message-ID: <20060329194914.GL15997@sorel.sous-sol.org> * G?rard Milmeister (gemi at bluewin.ch) wrote: > However when building: > Downloading sweep-0.9.1.tar.bz2... > --13:44:34-- > http://cvs.fedora.redhat.com/repo/extras/sweep/sweep-0.9.1.tar.bz2/7c346e28ff09c4a4f529a607ffd165f9/sweep-0.9.1.tar.bz2 > => `sweep-0.9.1.tar.bz2' > Resolving cvs.fedora.redhat.com... 209.132.176.51 > Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. > HTTP request sent, awaiting response... 404 Not Found > 13:44:34 ERROR 404: Not Found. > FINISHED --13:44:34-- > Downloaded: 0 bytes in 0 files > Could not download source file: sweep-0.9.1.tar.bz2 does not exist Yup, same here. And I noticed, the error during new-sources: Checking : cogito-0.17.1.tar.gz on https://cvs.fedora.redhat.com/repo/extras/upload.cgi... Uploading: cogito-0.17.1.tar.gz to https://cvs.fedora.redhat.com/repo/extras/upload.cgi... Unable to write to /repo/extras repository. thanks, -chris From rdieter at math.unl.edu Wed Mar 29 20:24:43 2006 From: rdieter at math.unl.edu (Rex Dieter) Date: Wed, 29 Mar 2006 14:24:43 -0600 Subject: File upload doesn't work In-Reply-To: <1143622945.3838.19.camel__39702.7489416816$1143622974$gmane$org@perun.kabelta.loc> References: <1143622945.3838.19.camel__39702.7489416816$1143622974$gmane$org@perun.kabelta.loc> Message-ID: <442AED0B.2060401@math.unl.edu> Tomas Mraz wrote: > The subject says it all. > > make new-source FILES=openoffice.org-dict-cs_CZ.tar.gz > > Checking : openoffice.org-dict-cs_CZ.tar.gz on > https://cvs.fedora.redhat.com/repo/extras/upload.cgi... > ERROR: could not check remote file status > make: *** [new-source] Error 255 > > curl: (22) The requested URL returned error: 500 Reported by Ville: "buildsys can't write to %sourcedir" http://bugzilla.redhat.com/bugzilla/187260 -- Rex From mattdm at mattdm.org Wed Mar 29 22:58:25 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 29 Mar 2006 17:58:25 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <442A219E.80404@redhat.com> References: <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> Message-ID: <20060329225825.GA26155@jadzia.bu.edu> On Wed, Mar 29, 2006 at 12:56:46AM -0500, Daniel J Walsh wrote: > >>Should also be wrapped in SELinux to make sure some random app does not > >>ask for this. If I am a user and NetworkManager pops a window saying [...] > >What would happen in the absence of SELinux? > It will ask the user and the user will say yes. > In the SELinux case it will still ask the user, but only an approved app > will be able to open the whole in the firewall. Sounds good, although I wonder if it might be nicer to implement this in a way similar to that described here: . Also, who decides which apps are "random" and which are approved? -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Thu Mar 30 01:10:40 2006 From: davidz at redhat.com (David Zeuthen) Date: Wed, 29 Mar 2006 20:10:40 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060329225825.GA26155@jadzia.bu.edu> References: <1143322829.20575.23.camel@daxter.boston.redhat.com> <44285196.7090208@redhat.com> <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> Message-ID: <1143681040.27889.22.camel@daxter.boston.redhat.com> On Wed, 2006-03-29 at 17:58 -0500, Matthew Miller wrote: > On Wed, Mar 29, 2006 at 12:56:46AM -0500, Daniel J Walsh wrote: > > >>Should also be wrapped in SELinux to make sure some random app does not > > >>ask for this. If I am a user and NetworkManager pops a window saying > [...] > > >What would happen in the absence of SELinux? > > It will ask the user and the user will say yes. Right. Maybe even the user needs to put in his own password or the superuser password. > > In the SELinux case it will still ask the user, but only an approved app > > will be able to open the whole in the firewall. It won't have to ask the user and I argue it shouldn't have to. > > Sounds good, although I wonder if it might be nicer to implement this in a > way similar to that described here: . Yea, that's what I was rambling about in my other mail. > Also, who decides which apps are "random" and which are approved? The thinking was that g-u-s would provide the system-level component for punching a hole that the httpd process launched by g-u-s would use. As such, only g-u-s would be able to use this. Other apps such as Banshee or Rhythmbox that wants to listen on a port too would provide similar helpers. This is not optimal but we gotta start somewhere. Ideally, the Fedora firewall (which is no more than a script plus a consolehelper powered GUI, ugh) would provide such a service along with a configuration framework. In fact, ideally there would be a freedesktop.org framework for punching holes through firewalls so everything would be solved upstream. One can always dream, yea? David From mattdm at mattdm.org Thu Mar 30 16:09:51 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Mar 2006 11:09:51 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143681040.27889.22.camel@daxter.boston.redhat.com> References: <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> Message-ID: <20060330160951.GA30773@jadzia.bu.edu> On Wed, Mar 29, 2006 at 08:10:40PM -0500, David Zeuthen wrote: > > Sounds good, although I wonder if it might be nicer to implement this in a > > way similar to that described here: . > Yea, that's what I was rambling about in my other mail. Are you interested in the run-as-user functionality for consolehelper I suggested in your blog comments? I'd hate to see yet another duplication of the how-to-let-regular-users-auth-for-higher-privs wheel. It seems like consolehelper has pretty much everything that's required for that part of the process, except as it stands, it only can execute things as root rather than running programs as your suggested unprivileged "system user". -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Thu Mar 30 16:54:54 2006 From: davidz at redhat.com (David Zeuthen) Date: Thu, 30 Mar 2006 11:54:54 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060330160951.GA30773@jadzia.bu.edu> References: <1143493340.4785.82.camel@orodruin.boston.redhat.com> <442853AF.7010800@redhat.com> <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> Message-ID: <1143737695.27889.51.camel@daxter.boston.redhat.com> On Thu, 2006-03-30 at 11:09 -0500, Matthew Miller wrote: > On Wed, Mar 29, 2006 at 08:10:40PM -0500, David Zeuthen wrote: > > > Sounds good, although I wonder if it might be nicer to implement this in a > > > way similar to that described here: . > > Yea, that's what I was rambling about in my other mail. > > Are you interested in the run-as-user functionality for consolehelper I > suggested in your blog comments? I'd hate to see yet another duplication of > the how-to-let-regular-users-auth-for-higher-privs wheel. > > It seems like consolehelper has pretty much everything that's required for > that part of the process, except as it stands, it only can execute things as > root rather than running programs as your suggested unprivileged "system > user". No, my view is that consolehelper is fundamentally flawed. Now that we have something like D-BUS there is absolutely no reason, apart from laziness, that you ever want run X11 programs as root or another user. Think for a minute about just how much code runs with root. Not to mention desktop integration issues [1]. Yet, I note that even more programs in FC5 use consolehelper. I do realize it's the best Fedora got so far (and that this message comes across as harsh, sorry) but that doesn't mean we shouldn't replace it with something more secure along the way. I think that we, as the Fedora project, should have a goal of completely removing consolehelper from the distribution some day. It's a lot of work but the first step is having a consensus that we can do better. Actually I posted about what I think needs to be done in Fedora to do this right here http://lists.freedesktop.org/archives/hal/2006-March/004797.html though I didn't put in too much time thinking about it. Consider it at least inspiration. Btw, a lot of people (with or without an @redhat.com email address, not that it matters) might not agree with me here. Make up your own mind about this. David [1] : Try running System->Administration->System Log Viewer; open a log file and look at the file chooser. Not to mention gconf issues. From mattdm at mattdm.org Thu Mar 30 17:44:22 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Mar 2006 12:44:22 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143737695.27889.51.camel@daxter.boston.redhat.com> References: <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> Message-ID: <20060330174422.GA3065@jadzia.bu.edu> On Thu, Mar 30, 2006 at 11:54:54AM -0500, David Zeuthen wrote: > No, my view is that consolehelper is fundamentally flawed. Now that we > have something like D-BUS there is absolutely no reason, apart from > laziness, that you ever want run X11 programs as root or another user. > Think for a minute about just how much code runs with root. Not to > mention desktop integration issues [1]. Well, having this would allow the existing consolehelper to take the place of the "polkit-su" tool you mention in . So instead of having a new thing, consolehelper could auth to access your 'polkit' user. It seems better to me to make this rather small change to consolehelper rather than to make yet another tool from scratch. Maybe I'm missing something important, though -- that often happens. :) > [1] : Try running System->Administration->System Log Viewer; open a log > file and look at the file chooser. Not to mention gconf issues. Oh, you don't have to convince me about this part. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Thu Mar 30 17:55:22 2006 From: davidz at redhat.com (David Zeuthen) Date: Thu, 30 Mar 2006 12:55:22 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060330174422.GA3065@jadzia.bu.edu> References: <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> Message-ID: <1143741323.1617.30.camel@daxter.boston.redhat.com> On Thu, 2006-03-30 at 12:44 -0500, Matthew Miller wrote: > Well, having this would allow the existing consolehelper to take the place > of the "polkit-su" tool you mention in > . So > instead of having a new thing, consolehelper could auth to access your > 'polkit' user. > > It seems better to me to make this rather small change to consolehelper > rather than to make yet another tool from scratch. Maybe I'm missing > something important, though -- that often happens. :) Indeed, the whole idea of using polkit-su have been abandoned after discussion on on the hal list when someone from SUN and SUSE proposed a better approach. Isn't open development great? However, it's all work in progress at the point and since it's rather complex and deals with privilege escalation I've started writing a spec how all this is supposed to work. I'm not done yet with the spec.. but this is how far I've got http://webcvs.freedesktop.org/*checkout*/hal/PolicyKit/doc/spec/polkit-spec.html and I hope at least the diagram explains what the point is. I do expect this to be baked at some point rather soon as it's holding back hal and gnome-mount releases :-) ... at least the difficult part of doing PAM over D-BUS is done and I already got proof of concept work.. so.. it's in a state of needing documentation of having a list of TODO's being worked on. If anyone wants to help out (I'm doing this mostly in my spare time as I'm tied up with other commitments at work) please join the hal list and send mail. Hope this helps. David From nicolas.mailhot at laposte.net Thu Mar 30 18:04:34 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Mar 2006 20:04:34 +0200 Subject: File upload doesn't work In-Reply-To: <1143661465.2562.5.camel@rousalka.dyndns.org> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> <1143658020.8872.1.camel@localhost.localdomain> <1143661465.2562.5.camel@rousalka.dyndns.org> Message-ID: <1143741877.16617.1.camel@rousalka.dyndns.org> The buildsystem is still failing on my packages. It's trying to download a strange source file : http://cvs.fedora.redhat.com/repo/extras/dejavu-fonts/dejavu-sfd-2.4.1.tar.gz/ea7ee1cd16880a8ce5b3e70d97c41fc8/dejavu-sfd-2.4.1.tar.gz 6926: dejavu-fonts (failed) Target:fedora-development-extras Submitter:nicolas.mailhot laposte net Source:dejavu-fonts-2_4_1-2_fc6 Started:Thu Mar 30 12:55:46 2006 Ended:Thu Mar 30 12:55:49 2006 (ran for 0 minutes) Result:" Error: could not make srpm for dejavu-fonts-2_4_1-2_fc6 - output was: Downloading dejavu-sfd-2.4.1.tar.gz... --12:55:49-- http://cvs.fedora.redhat.com/repo/extras/dejavu-fonts/dejavu-sfd-2.4.1.tar.gz/ea7ee1cd16880a8ce5b3e70d97c41fc8/dejavu-sfd-2.4.1.tar.gz => `dejavu-sfd-2.4.1.tar.gz' Resolving cvs.fedora.redhat.com... 209.132.176.51 Connecting to cvs.fedora.redhat.com|209.132.176.51|:80... connected. HTTP request sent, awaiting response... 404 Not Found 12:55:49 ERROR 404: Not Found. FINISHED --12:55:49-- Downloaded: 0 bytes in 0 files Could not download source file: dejavu-sfd-2.4.1.tar.gz does not exist make: *** [dejavu-sfd-2.4.1.tar.gz] Error 1 -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From dcbw at redhat.com Thu Mar 30 18:20:47 2006 From: dcbw at redhat.com (Dan Williams) Date: Thu, 30 Mar 2006 13:20:47 -0500 Subject: File upload doesn't work In-Reply-To: <1143741877.16617.1.camel@rousalka.dyndns.org> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> <1143658020.8872.1.camel@localhost.localdomain> <1143661465.2562.5.camel@rousalka.dyndns.org> <1143741877.16617.1.camel@rousalka.dyndns.org> Message-ID: <1143742847.4281.4.camel@localhost.localdomain> On Thu, 2006-03-30 at 20:04 +0200, Nicolas Mailhot wrote: > The buildsystem is still failing on my packages. It's trying to download > a strange source file : > > http://cvs.fedora.redhat.com/repo/extras/dejavu-fonts/dejavu-sfd-2.4.1.tar.gz/ea7ee1cd16880a8ce5b3e70d97c41fc8/dejavu-sfd-2.4.1.tar.gz It appears that's what you've got in sources... [localhost fedora-extras]# cd dejavu-fonts/devel/ [localhost devel]# ls CVS dejavu-fonts-register.xsl dejavu-fonts.spec Makefile sources [localhost devel]# cat sources ea7ee1cd16880a8ce5b3e70d97c41fc8 dejavu-sfd-2.4.1.tar.gz [localhost devel]# Try this to reupload the file, assuming the tarball has _not_ changed: echo "" > sources make upload FILES=dejavu-sfd-2.4.1.tar.gz rm -f sources cvs -z3 up sources make build Dan From nicolas.mailhot at laposte.net Thu Mar 30 18:34:27 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Mar 2006 20:34:27 +0200 Subject: File upload doesn't work In-Reply-To: <1143742847.4281.4.camel@localhost.localdomain> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> <1143658020.8872.1.camel@localhost.localdomain> <1143661465.2562.5.camel@rousalka.dyndns.org> <1143741877.16617.1.camel@rousalka.dyndns.org> <1143742847.4281.4.camel@localhost.localdomain> Message-ID: <1143743674.16617.5.camel@rousalka.dyndns.org> Le jeudi 30 mars 2006 ? 13:20 -0500, Dan Williams a ?crit : > On Thu, 2006-03-30 at 20:04 +0200, Nicolas Mailhot wrote: > > The buildsystem is still failing on my packages. It's trying to download > > a strange source file : > > > > http://cvs.fedora.redhat.com/repo/extras/dejavu-fonts/dejavu-sfd-2.4.1.tar.gz/ea7ee1cd16880a8ce5b3e70d97c41fc8/dejavu-sfd-2.4.1.tar.gz > > It appears that's what you've got in sources... I always upload full srpms using cvs-import so whatever mess is in sources has been created by the buildsystem. It's easier for me to produce a controlled srpm than understanding buildsys innards > > [localhost fedora-extras]# cd dejavu-fonts/devel/ > [localhost devel]# ls > CVS dejavu-fonts-register.xsl dejavu-fonts.spec Makefile sources > [localhost devel]# cat sources > ea7ee1cd16880a8ce5b3e70d97c41fc8 dejavu-sfd-2.4.1.tar.gz > [localhost devel]# > > Try this to reupload the file, assuming the tarball has _not_ changed: Will try this now. Thanks. > echo "" > sources > make upload FILES=dejavu-sfd-2.4.1.tar.gz > rm -f sources > cvs -z3 up sources > make build Regards, -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From nicolas.mailhot at laposte.net Thu Mar 30 19:07:36 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 30 Mar 2006 21:07:36 +0200 Subject: File upload doesn't work In-Reply-To: <1143743674.16617.5.camel@rousalka.dyndns.org> References: <1143622945.3838.19.camel@perun.kabelta.loc> <1143657623.14504.0.camel@scriabin.tannenrauch.ch> <1143658020.8872.1.camel@localhost.localdomain> <1143661465.2562.5.camel@rousalka.dyndns.org> <1143741877.16617.1.camel@rousalka.dyndns.org> <1143742847.4281.4.camel@localhost.localdomain> <1143743674.16617.5.camel@rousalka.dyndns.org> Message-ID: <1143745662.16617.6.camel@rousalka.dyndns.org> > Le jeudi 30 mars 2006 ? 13:20 -0500, Dan Williams a ?crit : > > echo "" > sources > > make upload FILES=dejavu-sfd-2.4.1.tar.gz > > rm -f sources > > cvs -z3 up sources > > make build This fixed my packages. Thanks a lot -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From pjones at redhat.com Thu Mar 30 21:00:13 2006 From: pjones at redhat.com (Peter Jones) Date: Thu, 30 Mar 2006 16:00:13 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060330174422.GA3065@jadzia.bu.edu> References: <1143507240.5625.12.camel@daxter.boston.redhat.com> <1143532289.29890.145.camel@greebo> <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> Message-ID: <1143752413.26084.82.camel@vroomfondel.internal.datastacks.com> On Thu, 2006-03-30 at 12:44 -0500, Matthew Miller wrote: > On Thu, Mar 30, 2006 at 11:54:54AM -0500, David Zeuthen wrote: > > No, my view is that consolehelper is fundamentally flawed. Now that we > > have something like D-BUS there is absolutely no reason, apart from > > laziness, that you ever want run X11 programs as root or another user. > > Think for a minute about just how much code runs with root. Not to > > mention desktop integration issues [1]. > > Well, having this would allow the existing consolehelper to take the place > of the "polkit-su" tool you mention in > . So > instead of having a new thing, consolehelper could auth to access your > 'polkit' user. > > It seems better to me to make this rather small change to consolehelper > rather than to make yet another tool from scratch. Maybe I'm missing > something important, though -- that often happens. :) The point is that "a tool to run things as root" is an awful design choice. The thing it's trying to solve is "a way for users who have administrative permissions to do administrative tasks". It used to be that our main model for doing this was "allow $USER to run $PROGRAM as root", which is the consolehelper and sudo way. But we had another one too -- USERCTL in network scripts. With dbus, we can take the USERCTL way another step forward. And in fact we have -- this is essentially the NetworkManager model. NM does the network configuration, but nm-applet has no such permissions. And unlike e.g. sudoers, the interface between nm-applet and NM doesn't lend itself to unconstrained exploits. -- Peter From mattdm at mattdm.org Thu Mar 30 22:26:47 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Mar 2006 17:26:47 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143741323.1617.30.camel@daxter.boston.redhat.com> References: <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> <1143741323.1617.30.camel@daxter.boston.redhat.com> Message-ID: <20060330222647.GA16325@jadzia.bu.edu> On Thu, Mar 30, 2006 at 12:55:22PM -0500, David Zeuthen wrote: > Indeed, the whole idea of using polkit-su have been abandoned after > discussion on on the hal list when someone from SUN and SUSE proposed a > better approach. Isn't open development great? Yes. :) > However, it's all work in progress at the point and since it's rather > complex and deals with privilege escalation I've started writing a spec > how all this is supposed to work. I'm not done yet with the spec.. but > this is how far I've got > http://webcvs.freedesktop.org/*checkout*/hal/PolicyKit/doc/spec/polkit-spec.html Okay, so no switching users at all. That looks pretty cool. I see "For details (like what user to authenticate as) see XXX" -- it'd make me very happy if XXX could include things like "for members of a given group, allow auth-as-self" (as consolehelper currently does). > and I hope at least the diagram explains what the point is. I do expect > this to be baked at some point rather soon as it's holding back hal and > gnome-mount releases :-) ... at least the difficult part of doing PAM > over D-BUS is done and I already got proof of concept work.. so.. it's > in a state of needing documentation of having a list of TODO's being > worked on. If anyone wants to help out (I'm doing this mostly in my > spare time as I'm tied up with other commitments at work) please join > the hal list and send mail. I'm interested but already horribly overcommitted. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Mar 30 22:28:19 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 30 Mar 2006 17:28:19 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143752413.26084.82.camel@vroomfondel.internal.datastacks.com> References: <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> <1143752413.26084.82.camel@vroomfondel.internal.datastacks.com> Message-ID: <20060330222819.GB16325@jadzia.bu.edu> On Thu, Mar 30, 2006 at 04:00:13PM -0500, Peter Jones wrote: > > It seems better to me to make this rather small change to consolehelper > > rather than to make yet another tool from scratch. Maybe I'm missing > > something important, though -- that often happens. :) > The point is that "a tool to run things as root" is an awful design > choice. The thing it's trying to solve is "a way for users who have > administrative permissions to do administrative tasks". Right, I get that. David's original proposal involved a tool to switch users to a *non-root* user. Consolehelper currently can't do that, but I was suggesting making it able to do so rather than writing a whole new program. But that is apparently moot now. I'll try to keep up. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From davidz at redhat.com Fri Mar 31 17:17:19 2006 From: davidz at redhat.com (David Zeuthen) Date: Fri, 31 Mar 2006 12:17:19 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <20060330222647.GA16325@jadzia.bu.edu> References: <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> <1143741323.1617.30.camel@daxter.boston.redhat.com> <20060330222647.GA16325@jadzia.bu.edu> Message-ID: <1143825440.8531.33.camel@daxter.boston.redhat.com> On Thu, 2006-03-30 at 17:26 -0500, Matthew Miller wrote: > > However, it's all work in progress at the point and since it's rather > > complex and deals with privilege escalation I've started writing a spec > > how all this is supposed to work. I'm not done yet with the spec.. but > > this is how far I've got > > http://webcvs.freedesktop.org/*checkout*/hal/PolicyKit/doc/spec/polkit-spec.html > > Okay, so no switching users at all. That looks pretty cool. I see "For > details (like what user to authenticate as) see XXX" -- it'd make me very > happy if XXX could include things like "for members of a given group, allow > auth-as-self" (as consolehelper currently does). Well, I'm sure that auth-as-self just because you are in a specific group is the answer here. Basically the thinking right now for PolicyKit is that this is defined on a per-privilege basis and we ship the OS with some sane defaults and the admin can change this later. So, for a given privilege (which, down the road, will include "changing the computer date/time", "mounting fixed disks", "use a webcam", "configure networking", "update OS with signed packages", "install signed software", "install unsigned software") the thinking is that the privilege in question specifies - if not authorized you auth either as yourself or as root - whether you may keep the privilege (for one time pain dialogs) - whether you may grant this privilege to other users (for one time pain dialogs) and that's basically it... One thing I may introduce later is the notion of "privilege profiles", e.g. the system can be put in e.g. the following profiles - Locked Down (everything requires auth) - Workstation (most things locked down, for example setting date and mounting removable drives requires auth) - Laptop (Most things not locked down, console users may set the time/date/timezone, mount both fixed and removable drives, update the OS with signed packages etc. without auth) - Unrestricted - (few things require auth; maybe not a good idea to include this at all) and a user goes into one of these profiles. I think that may solve what you need? Anyho, the nice thing is that the upstream packages using PolicyKit may define this policy themselves. For example, the GNOME clock applet authors would define policy (e.g. what is require to change the time/date/ timezone) for each of these profiles and I do think upstream is in a position to make such decisions better than a downstream distributor since they obviously are more familiar with the subject matter... (of course... a vendor like Fedora can always override this policy in the Fedora RPM).. But right now "privilege profiles" will only complicate the picture so I'm waiting a bit with these. But down the road I think this is what we're gonna if I can convince people (have to sell this to both upstream projects like GNOME, KDE and downstream like Fedora and other distros) that PolicyKit is a good idea... We'll see :-) One step at a time... David From davidz at redhat.com Fri Mar 31 17:19:01 2006 From: davidz at redhat.com (David Zeuthen) Date: Fri, 31 Mar 2006 12:19:01 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143825440.8531.33.camel@daxter.boston.redhat.com> References: <1143561256.4677.17.camel@daxter.boston.redhat.com> <44295DFD.6060805@redhat.com> <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> <1143741323.1617.30.camel@daxter.boston.redhat.com> <20060330222647.GA16325@jadzia.bu.edu> <1143825440.8531.33.camel@daxter.boston.redhat.com> Message-ID: <1143825541.8531.35.camel@daxter.boston.redhat.com> On Fri, 2006-03-31 at 12:17 -0500, David Zeuthen wrote: > Well, I'm sure that auth-as-self just because you are in a specific > group is the answer here. s/I'm sure/I'm not sure/ Ugh, sorry. David From mattdm at mattdm.org Fri Mar 31 19:01:28 2006 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 31 Mar 2006 14:01:28 -0500 Subject: Networking and the firewall (Was Re: Isn't it time for the encrypted file system???) In-Reply-To: <1143825440.8531.33.camel@daxter.boston.redhat.com> References: <20060329003359.GA16063@jadzia.bu.edu> <442A219E.80404@redhat.com> <20060329225825.GA26155@jadzia.bu.edu> <1143681040.27889.22.camel@daxter.boston.redhat.com> <20060330160951.GA30773@jadzia.bu.edu> <1143737695.27889.51.camel@daxter.boston.redhat.com> <20060330174422.GA3065@jadzia.bu.edu> <1143741323.1617.30.camel@daxter.boston.redhat.com> <20060330222647.GA16325@jadzia.bu.edu> <1143825440.8531.33.camel@daxter.boston.redhat.com> Message-ID: <20060331190128.GA31709@jadzia.bu.edu> On Fri, Mar 31, 2006 at 12:17:19PM -0500, David Zeuthen wrote: > Well, I'm sure that auth-as-self just because you are in a specific [^not, as per your reply to yourself] > group is the answer here. Basically the thinking right now for PolicyKit I don't think it should be _just because_, but I think that should be one way of describing who gets what. Not opposed to having other ways as well, but again in general I prefer to see "how can we make this work with existing mechanisms" rather than "oooh, shiny new wheels". > is that this is defined on a per-privilege basis and we ship the OS with > some sane defaults and the admin can change this later. > So, for a given privilege (which, down the road, will include "changing > the computer date/time", "mounting fixed disks", "use a webcam", > "configure networking", "update OS with signed packages", "install > signed software", "install unsigned software") the thinking is that the > privilege in question specifies > - if not authorized you auth either as yourself or as root > - whether you may keep the privilege (for one time pain dialogs) > - whether you may grant this privilege to other users (for one time > pain dialogs) FWIW, The shadow-utils pacakge provides the later for Unix supplementary groups have a mechanism through the 'gpasswd' command, which can allow an otherwise unprivledged user to manage group membership. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From gajownik at fedora.pl Fri Mar 31 21:55:44 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Fri, 31 Mar 2006 23:55:44 +0200 Subject: MODIFIED state in bugzilla Message-ID: <442DA560.7090904@fedora.pl> Hi! Is my bugzilla account broken or only Core developers can change state of a bug to "MODIFIED"? I don't have such a option ? http://img416.imageshack.us/img416/7552/bugzilla6ky.png I would like to show users that the fix will be released soon :) Regards, Dawid -- ^_*