Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 08:48:37 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote: | > On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk | > <[EMAIL PROTECTED]> wrote: | > | When does upstream get to install arbitrary content on my | > | computer? Upstream's build system gets to write stuff to $D, but | > | not to $ROOT (malice aside). The move to $ROOT, and anything | > | after that, is the ebuild writer's and the package manager's | > | responsibility. | > | > Well that's the point. We're talking malice here, | | You're talking malice here. I don't think everyone else is. Why else would a user want to refuse ebuilds that set userpriv? -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 08:00:18AM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 08:48:37 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | On Fri, Jan 12, 2007 at 07:15:53AM +, Ciaran McCreesh wrote: > | > On Fri, 12 Jan 2007 07:55:00 +0100 Harald van Dijk > | > <[EMAIL PROTECTED]> wrote: > | > | When does upstream get to install arbitrary content on my > | > | computer? Upstream's build system gets to write stuff to $D, but > | > | not to $ROOT (malice aside). The move to $ROOT, and anything > | > | after that, is the ebuild writer's and the package manager's > | > | responsibility. > | > > | > Well that's the point. We're talking malice here, > | > | You're talking malice here. I don't think everyone else is. > > Why else would a user want to refuse ebuilds that set userpriv? As a safeguard against accidental mistakes by upstream. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | > Why else would a user want to refuse ebuilds that set userpriv? | | As a safeguard against accidental mistakes by upstream. But ebuilds setting RESTRICT=userpriv are explicitly saying "we can't use userpriv not because of an accident but because the build system really needs elevated privs". If a user wants to be protected against accidental mistakes, they set FEATURES=userpriv and accidental mistakes are caught whilst intentional requirements are let through. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Quoting Ciaran McCreesh <[EMAIL PROTECTED]>: On Fri, 12 Jan 2007 16:02:01 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote: ... nothing to add here, sounds alright ... | Still, your point makes sense. But I hope that you will agree that | as long as FEATURES=userpriv exists it should be enforced. If it can | be circumvented the FEATURE may as well be removed and the whole | problem dealt with. No. userpriv is a nice safety feature to prevent against *accidental* screwups, but it has absolutely no value as a security feature. There are a small number of occasions where it really does need to be disabled, and that option should be available for the ebuild author without the need to worry about silly users refusing to install the package merely because of their misunderstanding of what userpriv does. And there are probably just as many situations when the RESTRICT is abused. I can vaguely recall only one such example: either vpopmail or courier-imap refuse to compile *not* as root which is silly. Anyway, what is userpriv? Just a useless safety feature? Why have it at all? This message was sent using IMP, the Internet Messaging Program. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 17:39:44 +0900 Georgi Georgiev <[EMAIL PROTECTED]> wrote: | And there are probably just as many situations when the RESTRICT is | abused. I can vaguely recall only one such example: either vpopmail | or courier-imap refuse to compile *not* as root which is silly. If that's really the case, start filing QA bugs. Unless, of course, there's a non-silly reason for it. | Anyway, what is userpriv? Just a useless safety feature? Why have it | at all? It's not useless. It's another way of protecting against accidental screwups. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 08:30:49AM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | > Why else would a user want to refuse ebuilds that set userpriv? > | > | As a safeguard against accidental mistakes by upstream. > > But ebuilds setting RESTRICT=userpriv are explicitly saying "we can't > use userpriv not because of an accident but because the build system > really needs elevated privs". If a user wants to be protected against > accidental mistakes, they set FEATURES=userpriv and accidental mistakes > are caught whilst intentional requirements are let through. Accidental mistakes in packages for which the ebuilds specify RESTRICT=userpriv are also let through. ACCEPT_RESTRICT=-userpriv (or whatever) would mean "I want to be protected against accidental mistakes, even if it means I can't install some software." -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | On Fri, Jan 12, 2007 at 08:30:49AM +, Ciaran McCreesh wrote: | > On Fri, 12 Jan 2007 09:11:11 +0100 Harald van Dijk | > <[EMAIL PROTECTED]> wrote: | > But ebuilds setting RESTRICT=userpriv are explicitly saying "we | > can't use userpriv not because of an accident but because the build | > system really needs elevated privs". If a user wants to be | > protected against accidental mistakes, they set FEATURES=userpriv | > and accidental mistakes are caught whilst intentional requirements | > are let through. | | Accidental mistakes in packages for which the ebuilds specify | RESTRICT=userpriv are also let through. Which is why a) developers check userpriv restricted packages much more carefully and b) there are other additional safety measures in place. | ACCEPT_RESTRICT=-userpriv (or whatever) would mean "I want to be | protected against accidental mistakes, even if it means I can't | install some software." Which is a silly and arbitrary distinction to make, and users should not be encouraged to do so. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 10:11:59AM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | ACCEPT_RESTRICT=-userpriv (or whatever) would mean "I want to be > | protected against accidental mistakes, even if it means I can't > | install some software." > > Which is a silly and arbitrary distinction to make, and users should > not be encouraged to do so. I don't think anyone was planning on encouraging people to mess with ACCEPT_RESTRICT if it gets implemented. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | On Fri, Jan 12, 2007 at 10:11:59AM +, Ciaran McCreesh wrote: | > On Fri, 12 Jan 2007 10:53:02 +0100 Harald van Dijk | > <[EMAIL PROTECTED]> wrote: | > | ACCEPT_RESTRICT=-userpriv (or whatever) would mean "I want to be | > | protected against accidental mistakes, even if it means I can't | > | install some software." | > | > Which is a silly and arbitrary distinction to make, and users should | > not be encouraged to do so. | | I don't think anyone was planning on encouraging people to mess with | ACCEPT_RESTRICT if it gets implemented. Implementing it *is* encouraging people to mess with it. There's yet to be any legitimate use for it demonstrated, so its only purpose is to allow people to do very silly things. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | I don't think anyone was planning on encouraging people to mess with > | ACCEPT_RESTRICT if it gets implemented. > > Implementing it *is* encouraging people to mess with it. Just like people are encouraged to use FEATURES="noauto noclean"? Implementing it is not encouraging people to mess with it. As for the legitimate use, I won't try to convince you that there are legitimate uses, but rather, even if it is silly, what does it matter to you? -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 13:04:21 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote: | > On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk | > <[EMAIL PROTECTED]> wrote: | > | I don't think anyone was planning on encouraging people to mess | > | with ACCEPT_RESTRICT if it gets implemented. | > | > Implementing it *is* encouraging people to mess with it. | | Just like people are encouraged to use FEATURES="noauto noclean"? | Implementing it is not encouraging people to mess with it. FEATURES has legitimate values. The feature as a whole is useful, even if some of the options have very restricted target audiences. | As for the legitimate use, I won't try to convince you that there are | legitimate uses, but rather, even if it is silly, what does it matter | to you? It matters in that there's even more time being spent going off on completely the wrong track that would be of more use elsewhere. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 12:19:18PM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 13:04:21 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | On Fri, Jan 12, 2007 at 11:55:44AM +, Ciaran McCreesh wrote: > | > On Fri, 12 Jan 2007 12:41:27 +0100 Harald van Dijk > | > <[EMAIL PROTECTED]> wrote: > | > | I don't think anyone was planning on encouraging people to mess > | > | with ACCEPT_RESTRICT if it gets implemented. > | > > | > Implementing it *is* encouraging people to mess with it. > | > | Just like people are encouraged to use FEATURES="noauto noclean"? > | Implementing it is not encouraging people to mess with it. > > FEATURES has legitimate values. The feature as a whole is useful, even > if some of the options have very restricted target audiences. So if ACCEPT_* were implemented in a way that lets you write ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox" you'd have no problem? After all, ACCEPT as a whole is useful, right? You can't group all features together in your logic, just because they share a variable. Please reconsider the point I tried to make. > | As for the legitimate use, I won't try to convince you that there are > | legitimate uses, but rather, even if it is silly, what does it matter > | to you? > > It matters in that there's even more time being spent going off on > completely the wrong track that would be of more use elsewhere. ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso if you combine the code for it with that for ACCEPT_LICENSE. More time has been spent on this thread than would have to be on the code... -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | > FEATURES has legitimate values. The feature as a whole is useful, | > even if some of the options have very restricted target audiences. | | So if ACCEPT_* were implemented in a way that lets you write | ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox" | you'd have no problem? After all, ACCEPT as a whole is useful, right? If ACCEPT were implemented that way, and there were no additional code involved in making restrict work in it, then it would be reduced from "silly misfeature" to "something that works by fluke but that you shouldn't do". | > | As for the legitimate use, I won't try to convince you that there | > | are legitimate uses, but rather, even if it is silly, what does | > | it matter to you? | > | > It matters in that there's even more time being spent going off on | > completely the wrong track that would be of more use elsewhere. | | ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso | if you combine the code for it with that for ACCEPT_LICENSE. More | time has been spent on this thread than would have to be on the | code... And what about the time spent arguing with users who start demanding that your package stop depping upon some random other package that happens to need userpriv turned off? And what about the time spent explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to get the results they expect and why userpriv and sandbox are not dangerous? Just because a feature *can* be added doesn't mean it *should*, no matter how trivial it is. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | > FEATURES has legitimate values. The feature as a whole is useful, > | > even if some of the options have very restricted target audiences. > | > | So if ACCEPT_* were implemented in a way that lets you write > | ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox" > | you'd have no problem? After all, ACCEPT as a whole is useful, right? > > If ACCEPT were implemented that way, and there were no additional code > involved in making restrict work in it, then it would be reduced from > "silly misfeature" to "something that works by fluke but that you > shouldn't do". FEATURES="noauto noclean" do not work by fluke. I'll ask you a second time to try to reconsider the point I was making. > | > | As for the legitimate use, I won't try to convince you that there > | > | are legitimate uses, but rather, even if it is silly, what does > | > | it matter to you? > | > > | > It matters in that there's even more time being spent going off on > | > completely the wrong track that would be of more use elsewhere. > | > | ACCEPT_RESTRICT is trivial to implement and to maintain, even moreso > | if you combine the code for it with that for ACCEPT_LICENSE. More > | time has been spent on this thread than would have to be on the > | code... > > And what about the time spent arguing with users who start demanding > that your package stop depping upon some random other package that > happens to need userpriv turned off? I'd like to give users a little bit more credit than to ask for dependencies on required packages to be dropped. (And as for dependencies on non-required packages, generally speaking, they should already be optional dependencies, or not dependencies at all.) > And what about the time spent > explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to > get the results they expect Presumably, the default for ACCEPT_RESTRICT would include all possible values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can only imagine to work in one way. > and why userpriv and sandbox are not > dangerous? > > Just because a feature *can* be added doesn't mean it *should*, no > matter how trivial it is. Correct, that reason by itself is not enough. My reply specifically addressed your comment, it was not a complete argument /for/ ACCEPT_RESTRICT. -- gentoo-dev@gentoo.org mailing list
RE: [gentoo-dev] [RFC] Ideas for projects...
On Thu, 2007-01-11 at 16:36 -0600, Jason Huebel wrote: > K, so my account hasn't been retired yet, so I'm making this comment as a > developer (at least until someone gets around to my retirement bug). :-) > > I really like blubb's idea here. Not just of implementing GLEP 42, but the > idea of having the Council responsible for overseeing and assigning tasks > for the implementation of ALL approved GLEPs. I would only see this as feasible if the Council: #1. was considered everyone's "manager" #2. could refuse to continue work on a GLEP, even ones previously approved #3. had some control over what people actually worked on #4. was involved in the GLEP process before the "approval" (I'm sure there's more...) Honestly, I see #3 and #4 as the biggest problems. Were it up to me, I likely wouldn't have approved *many* of the earlier GLEPs, knowing that they would be very hard to implement and oversee. A GLEP is an enhancement idea created within Gentoo. The idea I had was really for *new* ideas that wouldn't necessarily be covered under the scope of a GLEP. Remember that we don't really have control over what people do. We're currently more geared towards policy. The idea, as I suggested it, was to create new groups that *did* meet all of the above concepts. A group that "works" for the Council, on a project that has had oversight from the beginning, allowing us to come up with milestones and tasks *prior* to any other work being done. Think of it more like "contract developers" that are assigned a task, rather than trying to strong arm the current developer pool, which are more generic developers, into doing something. Basically, it is recruiting with the fore-knowledge of what you'll be working on, rather than us trying to add such controls into the current developer system. > Maybe GLEP 42 could be the pilot. :-) As far as I know, most of the portage-side stuff is done. > Jason Huebel > > -Original Message- > From: Simon Stelling [mailto:[EMAIL PROTECTED] > Sent: Thursday, January 11, 2007 4:24 PM > To: gentoo-dev@lists.gentoo.org > Subject: Re: [gentoo-dev] [RFC] Ideas for projects... > > I like the idea. Something really useful I could think of is *drums* > > the implementation of GLEP 42. > > -- > Kind Regards, > > Simon Stelling > Gentoo/AMD64 Developer > -- > gentoo-dev@gentoo.org mailing list > -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] Last Rites: app-admin/livecd-ng
Well, we've replaced this with catalyst, there's been no movement on it for 4 years now, "upstream" has abandoned it, and Release Engineering wants no part in it. It's been maintainer-needed for who knows how long. If someone doesn't step up in 30 days, it's getting the axe. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] New profiles/ChangeLog
There's a ChangeLog file in profiles/ChangeLog now. Please use it when making changes to things in profiles/*... Thanks, -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
[gentoo-dev] USE=tcltk split up
Hi, the USE flag tcltk should not be used anymore and migrated to tcl and/or tk flags. The corresponding bug [1] is very old, but there are still some packages missing (see comment #53 there). Remember that the latest stable (if any) and testing should have the split USE flags, so that built_with_use will not break. All affected teams/persons have been cced on that bug and should fix their packages until 10 Feb 2007. After that deadline I will fix the packages, trying not to break them, just speak up if you think it needs some special attention. All others relying on Tcl or Tk by built_with_use should adjust their ebuilds. Thanks for dumping this stinking, rotting bug. V-Li [1] http://bugs.gentoo.org/show_bug.cgi?id=17808> signature.asc Description: PGP signature
[gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
Ciaran pointed out that there are "a small number of occasions where it [the userpriv FEATURE] really does need to be disabled". I consequently decided to see what these legitimate reasons are but it appears that RESTRICT=userpriv is not needed in a lot of cases. Here is a list of all packages that currently have RESTRICT=userpriv or RESTRICT=nouserpriv (no idea why there are both). I also added a comment regarding the use of the RESTRICT but it would be nice if those in charge of a package could comment as well. # no idea about the following three, input appreciated app-admin/gps media-gfx/maya app-laptop/tp_smapi # emerged OK without the restrict, no idea if it works dev-db/firebird # No idea why, it's just a kernel module and should work fine (can't # test at the moment) net-dialup/ltmodem # seem fine even without the RESTRICT mail-filter/qmail-scanner net-misc/quagga # only older ebuilds have the restrict so these are probably OK sys-apps/mindi sys-apps/mindi-kernel # "because the vpopmail lib directory is locked down and non-root can't # access them" says a comment in the ebuild. I don't know why but with a # clean install of vpopmail the lib directory is not "locked down". Did # something change down the road? net-mail/qmailadmin # I figure it's the same reason as above? net-libs/courier-authlib net-mail/courier-imap # Bug 161765 net-mail/vpopmail # These are games... no idea why, input appreciated games-board/ggz-txt-client games-board/ggz-sdl-games games-board/ggz-gtk-games games-board/ggz-kde-games games-board/gnuchess-book games-board/ggz-kde-client games-board/ggz-gtk-client games-util/emilia-pinedit games-fps/quakeforge games-rpg/wastesedge -- (* Georgi Georgiev (* If life is merely a joke, the question (* *)[EMAIL PROTECTED]*) still remains: for whose amusement?*) (* http://www.gg3.net/ (*(* pgp0MLvRXDQCj.pgp Description: PGP signature
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Sat, Jan 13, 2007 at 12:53:35AM +0900, Georgi Georgiev wrote: > RESTRICT=userpriv or RESTRICT=nouserpriv (no idea why there are both). no.* is the old form for restricts; the 'no' chunk of it when seen, should be removed. ~harring pgpieaR6Z50In.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 14:05:49 +0100 Harald van Dijk <[EMAIL PROTECTED]>
wrote:
| On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
| > On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk
| > <[EMAIL PROTECTED]> wrote:
| > | > FEATURES has legitimate values. The feature as a whole is
| > | > useful, even if some of the options have very restricted target
| > | > audiences.
| > |
| > | So if ACCEPT_* were implemented in a way that lets you write
| > | ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox"
| > | you'd have no problem? After all, ACCEPT as a whole is useful,
| > | right?
| >
| > If ACCEPT were implemented that way, and there were no additional
| > code involved in making restrict work in it, then it would be
| > reduced from "silly misfeature" to "something that works by fluke
| > but that you shouldn't do".
|
| FEATURES="noauto noclean" do not work by fluke. I'll ask you a second
| time to try to reconsider the point I was making.
And noauto and noclean do have specific genuine use, so it's not a
fair comparison.
| > And what about the time spent arguing with users who start demanding
| > that your package stop depping upon some random other package that
| > happens to need userpriv turned off?
|
| I'd like to give users a little bit more credit than to ask for
| dependencies on required packages to be dropped. (And as for
| dependencies on non-required packages, generally speaking, they should
| already be optional dependencies, or not dependencies at all.)
Except that Portage doesn't do automatic dependency disabling for
non-required packages that are masked.
| > And what about the time spent
| > explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to
| > get the results they expect
|
| Presumably, the default for ACCEPT_RESTRICT would include all possible
| values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can
| only imagine to work in one way.
You miss the point (I explained it elsewhere in the thread). Turning on
ACCEPT_RESTRICT=fetch will not behave the sane way if a
fetch-restricted package has had all its ${A} things downloaded. It
will still show up as masked, which is not desired behaviour.
--
Ciaran McCreesh
Mail: ciaranm at ciaranm.org
Web : http://ciaranm.org/
Paludis, the secure package manager : http://paludis.pioto.org/
signature.asc
Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 05:19:02PM +, Ciaran McCreesh wrote:
> On Fri, 12 Jan 2007 14:05:49 +0100 Harald van Dijk <[EMAIL PROTECTED]>
> wrote:
> | On Fri, Jan 12, 2007 at 12:46:58PM +, Ciaran McCreesh wrote:
> | > On Fri, 12 Jan 2007 13:30:11 +0100 Harald van Dijk
> | > <[EMAIL PROTECTED]> wrote:
> | > | > FEATURES has legitimate values. The feature as a whole is
> | > | > useful, even if some of the options have very restricted target
> | > | > audiences.
> | > |
> | > | So if ACCEPT_* were implemented in a way that lets you write
> | > | ACCEPT="keyword:~x86 -license:QPL-1.0 restrict:sandbox"
> | > | you'd have no problem? After all, ACCEPT as a whole is useful,
> | > | right?
> | >
> | > If ACCEPT were implemented that way, and there were no additional
> | > code involved in making restrict work in it, then it would be
> | > reduced from "silly misfeature" to "something that works by fluke
> | > but that you shouldn't do".
> |
> | FEATURES="noauto noclean" do not work by fluke. I'll ask you a second
> | time to try to reconsider the point I was making.
>
> And noauto and noclean do have specific genuine use, so it's not a
> fair comparison.
Again irrelevant to the point, since regardless of whether they have
some small valid use, they should not be recommended to users.
> | > And what about the time spent arguing with users who start demanding
> | > that your package stop depping upon some random other package that
> | > happens to need userpriv turned off?
> |
> | I'd like to give users a little bit more credit than to ask for
> | dependencies on required packages to be dropped. (And as for
> | dependencies on non-required packages, generally speaking, they should
> | already be optional dependencies, or not dependencies at all.)
>
> Except that Portage doesn't do automatic dependency disabling for
> non-required packages that are masked.
Okay, that's a fair enough point; it's possible to make portage handle
that case nicer, and if ACCEPT_* (it also applies to LICENSE) has to
wait until it does, I won't object.
> | > And what about the time spent
> | > explaining to everyone why fetch can't be used in ACCEPT_RESTRICT to
> | > get the results they expect
> |
> | Presumably, the default for ACCEPT_RESTRICT would include all possible
> | values, so the case to consider is ACCEPT_RESTRICT=-fetch, which I can
> | only imagine to work in one way.
>
> You miss the point (I explained it elsewhere in the thread). Turning on
> ACCEPT_RESTRICT=fetch will not behave the sane way if a
> fetch-restricted package has had all its ${A} things downloaded. It
> will still show up as masked, which is not desired behaviour.
I'm not sure what you mean.
With ACCEPT_RESTRICT=fetch, portage should behave as it currently does:
be quiet if the sources are available, complain if they're not. If
portage would always complain, yeah, that's bad, but I don't see why it
would do that.
With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with
RESTRICT=fetch, so portage /should/ complain regardless of whether the
sources are available.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On Sunday 07 January 2007 11:27, Alon Bar-Lev wrote:
> 1. Add default.
we've gone this route ... if/when an issue comes up where someone is
inheriting autotools but they're using it conditionally, we'll revisit this
autotools.eclass:
[[ -z ${WANT_AUTOCONF} ]] && WANT_AUTOCONF="latest"
[[ -z ${WANT_AUTOMAKE} ]] && WANT_AUTOMAKE="latest"
-mike
pgpsl2mdH5eUe.pgp
Description: PGP signature
Re: [gentoo-dev] New profiles/ChangeLog
Chris Gianelloni wrote: > There's a ChangeLog file in profiles/ChangeLog now. Please use it when > making changes to things in profiles/*... Should we prefer this location for trees that already have a ChangeLog in them as well? It's kind of random which places have a ChangeLog and which don't. [EMAIL PROTECTED] profiles $ find . -name ChangeLog ./ChangeLog ./default-linux/alpha/ChangeLog ./default-linux/amd64/ChangeLog ./default-linux/hppa/ChangeLog ./default-linux/ia64/ChangeLog ./default-linux/ppc/ChangeLog ./default-linux/sparc/ChangeLog ./default-linux/x86/ChangeLog ./hardened/x86/ChangeLog Thanks, Donnie signature.asc Description: OpenPGP digital signature
Re: [gentoo-core] Re: [gentoo-dev] New profiles/ChangeLog
On Fri, 2007-01-12 at 10:00 -0800, Donnie Berkholz wrote: > Chris Gianelloni wrote: > > There's a ChangeLog file in profiles/ChangeLog now. Please use it when > > making changes to things in profiles/*... > > Should we prefer this location for trees that already have a ChangeLog > in them as well? It's kind of random which places have a ChangeLog and > which don't. > > [EMAIL PROTECTED] profiles $ find . -name ChangeLog > ./ChangeLog > ./default-linux/alpha/ChangeLog > ./default-linux/amd64/ChangeLog > ./default-linux/hppa/ChangeLog > ./default-linux/ia64/ChangeLog > ./default-linux/ppc/ChangeLog > ./default-linux/sparc/ChangeLog > ./default-linux/x86/ChangeLog > ./hardened/x86/ChangeLog Not really randomshould be something akin to one per arch (for releng/arch team purposes) and then on global one to accommodate everything else... --Dan signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On 1/12/07, Mike Frysinger <[EMAIL PROTECTED]> wrote:
On Sunday 07 January 2007 11:27, Alon Bar-Lev wrote:
> 1. Add default.
we've gone this route ... if/when an issue comes up where someone is
inheriting autotools but they're using it conditionally, we'll revisit this
autotools.eclass:
[[ -z ${WANT_AUTOCONF} ]] && WANT_AUTOCONF="latest"
[[ -z ${WANT_AUTOMAKE} ]] && WANT_AUTOMAKE="latest"
-mike
Thanks!
After you commit this, I will go over all my packages and remove the
latest setting.
Best Regards,
Alon Bar-Lev.
--
gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On Friday 12 January 2007 13:14, Mike Frysinger wrote: > if/when an issue comes up where someone is > inheriting autotools but they're using it conditionally, we'll revisit this seems Diego is two steps ahead ... set the vars to "none" :) -mike pgpt5VjQENLt7.pgp Description: PGP signature
Re: [gentoo-dev] autotools eclass - set default for WANT_AUTO*
On Friday 12 January 2007 13:37, Alon Bar-Lev wrote: > After you commit this Diego already did -mike -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: > # no idea about the following three, input appreciated > app-admin/gps > media-gfx/maya This one doesn't need RESTRICT=userpriv (at least my 8.0 ebuild in my overlay doesn't) from my testing. > # These are games... no idea why, input appreciated > games-board/ggz-txt-client > games-board/ggz-sdl-games > games-board/ggz-gtk-games > games-board/ggz-kde-games > games-board/gnuchess-book > games-board/ggz-kde-client > games-board/ggz-gtk-client > games-util/emilia-pinedit > games-fps/quakeforge > games-rpg/wastesedge No clue. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | > And noauto and noclean do have specific genuine use, so it's not a | > fair comparison. | | Again irrelevant to the point, since regardless of whether they have | some small valid use, they should not be recommended to users. Not at all. They have value for developers. ACCEPT_RESTRICT has no value for anyone. | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with | RESTRICT=fetch, so portage /should/ complain regardless of whether the | sources are available. Which is my point -- that's a stupid thing to request. A sensible thing to request would be "mask anything that will require me to fetch something manually". -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
[gentoo-dev] Re: profile changelogs
Normally, I wouldn't send private responses to the list, but since this is something everyone can use (and nothing "private") I am making an exception. On Fri, 2007-01-12 at 09:22 -0700, Steve Dibb wrote: > Chris, > > Would that Changelog in profiles/ need to be updated for stuff > recursively as well? I made some changes to default-linux/amd64/ stuff, > but I added the changes to the ChangeLog for that directory. That would be correct. The rightmost ChangeLog should be used. What I am hoping we end up with is: profiles/default-linux/$arch/ChangeLog: This is for the arch team/releng/anyone else who make changes in an architecture's profile. This would be for adding, for example, things to use.mask or package.mask on the no-multilib profile(s). profiles/default-linux/ChangeLog: This is for stuff affecting Linux only. profiles/base/ChangeLog: This is for anything affecting everyone. profiles/ChangeLog: This is for new USE/package.mask and such. Of course, other ChangeLog entries could be added to different locations, but this is my trying to keep the number of ChangeLog locations as small as possible. I'm definitely open to any other suggestions or ideas. I just think this is probably the easiest for the time being. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: > # These are games... no idea why, input appreciated > games-board/ggz-txt-client > games-board/ggz-sdl-games > games-board/ggz-gtk-games > games-board/ggz-kde-games > games-board/gnuchess-book > games-board/ggz-kde-client > games-board/ggz-gtk-client > games-util/emilia-pinedit > games-fps/quakeforge > games-rpg/wastesedge They have to be able to read /usr/games/lib. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
Tristan Heaven <[EMAIL PROTECTED]> wrote: > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: > > # These are games... no idea why, input appreciated > > games-board/ggz-txt-client > > games-board/ggz-sdl-games > > games-board/ggz-gtk-games > > games-board/ggz-kde-games > > games-board/gnuchess-book > > games-board/ggz-kde-client > > games-board/ggz-gtk-client > > games-util/emilia-pinedit > > games-fps/quakeforge > > games-rpg/wastesedge > > They have to be able to read /usr/games/lib. Wouldn't it be more sensible, then, to add /usr/games/lib to SANDBOX_READ or whatever is the appropriate variable? -- There are problems in today's world that cannot be solved by the level of thinking that created them. -- Albert Einstein pgpdxRETVB3Vy.pgp Description: PGP signature
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Fri, 2007-01-12 at 13:05 -0800, Drake Wyrm wrote: > Tristan Heaven <[EMAIL PROTECTED]> wrote: > > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: > > > # These are games... no idea why, input appreciated > > > games-board/ggz-txt-client > > > games-board/ggz-sdl-games > > > games-board/ggz-gtk-games > > > games-board/ggz-kde-games > > > games-board/gnuchess-book > > > games-board/ggz-kde-client > > > games-board/ggz-gtk-client > > > games-util/emilia-pinedit > > > games-fps/quakeforge > > > games-rpg/wastesedge > > > > They have to be able to read /usr/games/lib. > > Wouldn't it be more sensible, then, to add /usr/games/lib to > SANDBOX_READ or whatever is the appropriate variable? It has nothing to do with the sandbox. It's because /usr/games/lib isn't readable to people outside the "games" group. -- Chris Gianelloni Release Engineering Strategic Lead Alpha/AMD64/x86 Architecture Teams Games Developer/Council Member/Foundation Trustee Gentoo Foundation signature.asc Description: This is a digitally signed message part
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Fri, 12 Jan 2007 19:36:06 + Tristan Heaven <[EMAIL PROTECTED]> wrote: > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: > They have to be able to read /usr/games/lib. In which case adding the portage user to the games group seems overall to be a better solution than requiring root privileges to build. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Last rites: net-p2p/teknap
# Raúl Porcel <[EMAIL PROTECTED]> (12 Jan 2007) # Upstream dead almost 3 years ago and doesn't compile with GCC 4.x. # Pending removal 12 Feb 2007, bug 153268 net-p2p/teknap -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Fri, Jan 12, 2007 at 10:46:36PM +, Stephen Bennett wrote: > > On Sat, 2007-01-13 at 00:53 +0900, Georgi Georgiev wrote: > > They have to be able to read /usr/games/lib. > In which case adding the portage user to the games group seems overall > to be a better solution than requiring root privileges to build. The problem then is that when sandbox is not used (no FEATURES=usersandbox), the portage user has too much access to the games stuff in general. The vpopmail stuff has/has a similar issue (upstream is working on solving it via a different avenue at which point the problem will go away). There is a little bit of well-audited code that runs setgid vpopmail with privilege separation stuff. This is so that it can authenticate against a file that contains a password (for connecting to MySQL for user verification). However, if you need to link against it during the build process, you need to either be root, or be in the group with access to the file you are linking against. Putting the portage user into the special group would mean that somebody could steal the MySQL password - so do you RESTRICT=userpriv, or fail the build? -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpuY5z3pQkFS.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote: > On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk <[EMAIL PROTECTED]> > | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with > | RESTRICT=fetch, so portage /should/ complain regardless of whether the > | sources are available. > > Which is my point -- that's a stupid thing to request. A sensible thing > to request would be "mask anything that will require me to fetch > something manually". It's not a stupid thing to request to install only packages that allow you to emerge -e world if / gets corrupted. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
Chris Gianelloni wrote: > Imagine you have userpriv in FEATURES. If an ebuild has > RESTRICT=userpriv, it *WILL* disable userpriv, no matter what the user > does. Adding ACCEPT_RESTRICT allows the user to not list userpriv (or > -userpriv if userpriv is on by default) and the ebuild WILL NOT RUN if > it requires userpriv be disabled. What should it do then? Does emerge error out, or is there some kind of indication or message that the package going to be ignored? Does nomerge get some colored letters when you do emerge -Dtvp world? Do we show this in the deptree or when it's time for the package to be built? I don't like that portage will override a user's FEATURES, especially if it's something explicitly specified and silently ignored. I don't think ACCEPT_RESTRICT is the way to handle it though. I would rather portage display a message explaining the restriction and then a) continue if the package is part of a larger target (ie. emerge -DtvuNp world) and currently installed, or b) error if the package was specified on the command line or is not currently installed. Honestly, that would be scratching an itch of mine with fetch-restricted ebuilds killing an unattended emerge world, but it might serve as a model for future stuff like RESTRICT=unattended too. -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
On Fri, 12 Jan 2007 15:08:15 -0800 "Robin H. Johnson" <[EMAIL PROTECTED]> wrote: > Putting the portage user into the special group would mean that > somebody could steal the MySQL password - so do you > RESTRICT=userpriv, or fail the build? If someone can subvert Portage's build process they can root your system no matter what uid is used for the build itself. Userpriv and sandbox are not and cannot be security measures; they only guard against accidental breakage in makefiles, so that argument is relatively bogus since if malice is brought into the equation the portage user has effective root already. -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Re: [RFC] Ideas for projects...
Chris Gianelloni wrote: > Submit your ideas here, so we can discuss them. I will be choosing one > idea that we think we can accomplish to test out the idea of > Council-driven projects. How far was Curtis from finishing www-redesign? -- by design, by neglect dirtyepic gentoo orgfor a fact or just for effect 9B81 6C9F E791 83BB 3AB3 5B2D E625 A073 8379 37E8 (0x837937E8) signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] Abusing RESTRICT={no,}userpriv (was [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT)
maillog: 12/01/2007-15:08:15(-0800): Robin H. Johnson types > > The vpopmail stuff has/has a similar issue (upstream is working on > solving it via a different avenue at which point the problem will go > away). But I tried "emerge vpopmail" on a clean system... the /var/vpopmail/lib and include directories along with all files in them are in fact world readable. And there is exactly one vpopmail ebuild in the portage tree. Here is what happens after emerge vpopmail (with an empty PORTDIR_OVERLAY variable) on a system without a vpopmail user and a /var/vpopmail directory: possum ~ # find /var/vpopmail -ls 3492640 drwxr-xr-x 7 vpopmail root 192 Jan 13 12:54 /var/vpopmail 4718471 drwxr-xr-x 2 root root 784 Jan 13 12:54 /var/vpopmail/bin 476915 80 -rwx--x--x 1 root root79832 Jan 13 12:54 /var/vpopmail/bin/vchangepw 476916 80 -rwx--x--x 1 root root81016 Jan 13 12:54 /var/vpopmail/bin/vdeloldusers 476917 104 -rwx--x--x 1 root root 103960 Jan 13 12:54 /var/vpopmail/bin/vpopmaild 476918 88 -rwx--x--x 1 root root86392 Jan 13 12:54 /var/vpopmail/bin/vpopbull 4784594 -rwxr-xr-x 1 root root 1480 Jan 13 12:54 /var/vpopmail/bin/vpopmail-Maildir-dotmaildir-fix.sh 476919 80 -rwx--x--x 1 root root79128 Jan 13 12:54 /var/vpopmail/bin/vkill 476920 80 -rwx--x--x 1 root root81208 Jan 13 12:54 /var/vpopmail/bin/dotqmail2valias 476921 84 -rwx--x--x 1 root root83352 Jan 13 12:54 /var/vpopmail/bin/vconvert 476922 80 -rwx--x--x 1 root root79800 Jan 13 12:54 /var/vpopmail/bin/vaddaliasdomain 476923 80 -rwx--x--x 1 root root79352 Jan 13 12:54 /var/vpopmail/bin/vdeluser 476924 80 -rwx--x--x 1 root root78616 Jan 13 12:54 /var/vpopmail/bin/clearopensmtp 476925 84 -rwx--x--x 1 root root82264 Jan 13 12:54 /var/vpopmail/bin/vdominfo 476926 80 -rwx--x--x 1 root root79800 Jan 13 12:54 /var/vpopmail/bin/vdeldomain 478432 84 -rwx--x--x 1 root root83896 Jan 13 12:54 /var/vpopmail/bin/vuserinfo 478435 80 -rwx--x--x 1 root root78648 Jan 13 12:54 /var/vpopmail/bin/vmkpasswd 478437 84 -rwx--x--x 1 root root83128 Jan 13 12:54 /var/vpopmail/bin/vmoduser 478440 84 -rwx--x--x 1 root root82264 Jan 13 12:54 /var/vpopmail/bin/valias 478441 92 -rws--x--x 1 root vpopmail90624 Jan 13 12:54 /var/vpopmail/bin/vchkpw 478433 80 -rwx--x--x 1 root root79704 Jan 13 12:54 /var/vpopmail/bin/vipmap 478443 84 -rwx--x--x 1 root root82264 Jan 13 12:54 /var/vpopmail/bin/vadduser 478439 80 -rwx--x--x 1 root root80056 Jan 13 12:54 /var/vpopmail/bin/vsetuserquota 478442 92 -rwx--x--x 1 root root90456 Jan 13 12:54 /var/vpopmail/bin/vmoddomlimits 478444 80 -rwx--x--x 1 root root79640 Jan 13 12:54 /var/vpopmail/bin/vpasswd 478438 88 -rwx--x--x 1 root root8 Jan 13 12:54 /var/vpopmail/bin/vdelivermail 478434 84 -rwx--x--x 1 root root82264 Jan 13 12:54 /var/vpopmail/bin/vadddomain 4784650 lrwxrwxrwx 1 root root 31 Jan 13 12:54 /var/vpopmail/doc -> /usr/share/doc/vpopmail-5.4.16/ 6667700 drwxr-xr-x 2 root root 160 Jan 13 12:54 /var/vpopmail/etc 6667710 lrwxrwxrwx 1 root root 18 Jan 13 12:54 /var/vpopmail/etc/vpopmail.mysql -> /etc/vpopmail.conf 4698944 -rw-r--r-- 1 root root 1143 Jan 13 12:54 /var/vpopmail/etc/vlimits.default 4698924 -rw-r--r-- 1 root root 24 Jan 13 12:54 /var/vpopmail/etc/inc_deps 4698934 -rw-r--r-- 1 root root 80 Jan 13 12:54 /var/vpopmail/etc/lib_deps 6667720 drwxr-xr-x 2 vpopmail vpopmail 80 Jan 13 12:54 /var/vpopmail/lib 478436 172 -rw-r--r-- 1 root root 175382 Jan 13 12:54 /var/vpopmail/lib/libvpopmail.a 6667730 drwxr-xr-x 2 vpopmail vpopmail 96 Jan 13 12:54 /var/vpopmail/domains 4784500 -rw-r--r-- 1 root root0 Jan 13 12:54 /var/vpopmail/domains/.keep_net-mail_vpopmail-0 6667830 drwxr-xr-x 2 root root 200 Jan 13 12:54 /var/vpopmail/include 4698988 -r--r--r-- 1 root root 7679 Jan 13 12:54 /var/vpopmail/include/vpopmail_config.h 4699008 -r--r--r-- 1 root root 7679 Jan 13 12:54 /var/vpopmail/include/config.h 4699038 -r--r--r-- 1 root root 4342 Jan 13 12:54 /var/vpopmail/include/vauth.h 4699054 -r--r--r-- 1 root root 2062 Jan 13 12:54 /var/vpopmail/include/vlimits.h 4698998 -r--r--r-- 1 root root 8192 Jan 13 12:54 /var/vpopmail/include/vpopmail.h -- \Georgi Georgiev \ It's not the valleys in life I dread so\ / [EMAIL PROTECTED]/ much as the dips. -- Garfield / \ http://www.gg3.
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
maillog: 13/01/2007-02:05:45(+0100): Harald van Dijk types > On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote: > > On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk <[EMAIL PROTECTED]> > > | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages with > > | RESTRICT=fetch, so portage /should/ complain regardless of whether the > > | sources are available. > > > > Which is my point -- that's a stupid thing to request. A sensible thing > > to request would be "mask anything that will require me to fetch > > something manually". > > It's not a stupid thing to request to install only packages that allow > you to emerge -e world if / gets corrupted. Consider how portage shows an indication in the --pretend (or --ask) output if a package requires manual fetching or if the download is already done. You know that you have to either fetch the files or avoid the package. With ACCEPT_RESTRICT=fetch it would have failed anyway. Something similar could be done about userpriv. Another red letter indicating that a package will compile as root (and the user is free to go ahead or abort as they see fit). The letter can be green if userpriv is not in FEATURES. The problem I am having with RESTRICT=userpriv is that it is *silent* about what it does. If there were some indication I would have been happy. Anyone else feel the same way? -- (* Georgi Georgiev (* Mal: "I, uh, better go see how the (* *)[EMAIL PROTECTED]*) inevitable mutiny is coming along..." *) (* http://www.gg3.net/ (*(* -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] Re: [RFC] Ideas for projects...
Ryan Hill wrote: > Chris Gianelloni wrote: > >> Submit your ideas here, so we can discuss them. I will be choosing one >> idea that we think we can accomplish to test out the idea of >> Council-driven projects. > > How far was Curtis from finishing www-redesign? > The whole thing was pretty much scrapped. The CSS was done to some extent, but our underlying xsl backend hadn't been finished. As far as I know the redesign has been suspended indefinitely. *and then* Curtis disappeared some months ago, to top it off. signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Sat, 13 Jan 2007 02:05:45 +0100 Harald van Dijk <[EMAIL PROTECTED]> wrote: | On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote: | > On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk | > <[EMAIL PROTECTED]> | > | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages | > | with RESTRICT=fetch, so portage /should/ complain regardless of | > | whether the sources are available. | > | > Which is my point -- that's a stupid thing to request. A sensible | > thing to request would be "mask anything that will require me to | > fetch something manually". | | It's not a stupid thing to request to install only packages that allow | you to emerge -e world if / gets corrupted. Huh? No, you're grasping at straws here. If / gets corrupted then you're screwed. -- Ciaran McCreesh Mail: ciaranm at ciaranm.org Web : http://ciaranm.org/ Paludis, the secure package manager : http://paludis.pioto.org/ signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Sat, Jan 13, 2007 at 05:45:31AM +, Ciaran McCreesh wrote: > On Sat, 13 Jan 2007 02:05:45 +0100 Harald van Dijk <[EMAIL PROTECTED]> > wrote: > | On Fri, Jan 12, 2007 at 07:12:00PM +, Ciaran McCreesh wrote: > | > On Fri, 12 Jan 2007 18:42:20 +0100 Harald van Dijk > | > <[EMAIL PROTECTED]> > | > | With ACCEPT_RESTRICT=-fetch, you tell it you don't want packages > | > | with RESTRICT=fetch, so portage /should/ complain regardless of > | > | whether the sources are available. > | > > | > Which is my point -- that's a stupid thing to request. A sensible > | > thing to request would be "mask anything that will require me to > | > fetch something manually". > | > | It's not a stupid thing to request to install only packages that allow > | you to emerge -e world if / gets corrupted. > > Huh? No, you're grasping at straws here. If / gets corrupted then > you're screwed. I have personally had my / corrupted more than once, and I have been able to re-install everything without a livecd more than once too. -- gentoo-dev@gentoo.org mailing list
