Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wed, 2007-01-10 at 13:32 -0500, Mike Frysinger wrote: On Wednesday 10 January 2007 13:03, Jakub Moc wrote: And RESTRICT=sandbox is still completely unneeded, commercial packages or not... We don't need to introduce a special RESTRICT because of two borked packages in the tree and we should not introduce any more packages borked in a similar way into the tree. for future reference, keep your replies on topic and stupid rants out this is what you should have said in the first place we need a real solution for emacs/gcl ... exporting SANDBOX_ON=0 is not the answer -mike Here's a real solution for gcl: http://bugs.gentoo.org/show_bug.cgi?id=161041#c7 Y'know, if even a tenth of the energy that went into this flame war had gone into solving the emacs sandbox breakage, I'm pretty sure that would have been fixed by now as well. Funny, that. Ed -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote: getting quite hostile. The only thing I can possibly gather from this is you're intentionally being fucking dense, so it's not worth my time. How is it that you can ignore half an email and only respond to something out of context and then still fuck *that* up? Chill fellas. Imo, FEATURES = things we say 'portage, mutate everything like so' , and RESTRICT to my way of thinking is per-package dependant, more like USE flags, except more general and apply to all packages. I think one of the arguments is that it provides a level of communication between the package and portage/user as to what types of things a package is permitted to do. Say for example, we have a package called child ( forgive me If I've also missunderstood the point of this feature ) . Now by default, say all packages are not allowed to go outside, but package child has a unique situation where it needs to perform go outside in order to merge. The child package of course is naïeve and knows nothing about the outside environment that its trying to install into. So the child reports a RESTRICT='go outside' ( if i understand correctly ) , and it can only go outside by doing this 'RESTRICT request. By default, the environment has ACCEPT_RESTRICT=go outside in it. Now the environment owner may be running a situation where they dont want apps 'going outside' and potentially trashing thier manicured lawn so they say ACCEPT_RESTRICT=-go outside , and after that instruction, all ebuilds requesting to go outside will be bluntly denied. Is that analogy of any sence to anybody?, or Have I completely missed the plot too :S - Kent -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Thu, 2007-01-11 at 09:07 +0900, Georgi Georgiev wrote: Further, by adopting ACCEPT_RESTRICT, it would be possible to be able to say: ACCEPT_RESTRICT=-sandbox: Do not let any ebuild touch anything outside the sandbox. ACCEPT_RESTRICT=-userpriv: Do not let any ebuild run with elevated privileges. Exactly. Currently, it's read like this: FEATURES, RESTRICT What we're proposing is this: FEATURES, RESTRICT, ACCEPT_RESTRICT 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. -- 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] deprecating /etc/make.profile
On Wed, 10 Jan 2007 22:30:32 -0800 Ned Ludd [EMAIL PROTECTED] wrote: On Thu, 2007-01-11 at 17:37 +1300, Kent Fredric wrote: On 1/11/07, Marius Mauch [EMAIL PROTECTED] wrote: And I assume there is a non-trivial number of custom scripts out there using make.profile, but that's nothing we can do about. You could give them all a grace period for which have to comply with the new standard by then end of it, and have ( during that grace period ) an automatic symlink generation based on that make.conf flag. And just to make sure, I doubt it would be too difficult to have an application that analyises packages as they install to check whether they reference make.profile or not, and flag a QA warning if they do. And packages that don't switch to the standard by the end of the grace period I guess we'll see on a last rites bulletin ;) Or we/gentoo could just support it and stop breaking the end user. A simple expedient would be to have the package manager re-create the symlink according to the variable, whenever it is run. -- Kevin F. Quinn signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote: On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger [EMAIL PROTECTED] | as stated in original e-mail, unattended/sandbox are just some | examples, not the only ones So which RESTRICT values *should* the user legitimately have to care about? On Wednesday 10 January 2007 16:40, Chris Gianelloni wrote: I am a user. I don't want any of my compiles executing with elevated privileges. I have FEATURES=userpriv. Package foo has RESTRICT=userpriv. I don't have ACCEPT_RESTRICT=userpriv. When I try to install package foo, it fails, because I don't want to allow RESTRICT=userpriv. -mike pgpc9iPhH1NHC.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Thu, 11 Jan 2007 11:56:09 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote: | On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger | [EMAIL PROTECTED] | | as stated in original e-mail, unattended/sandbox are just some | | examples, not the only ones | | So which RESTRICT values *should* the user legitimately have to care | about? | | On Wednesday 10 January 2007 16:40, Chris Gianelloni wrote: | I am a user. I don't want any of my compiles executing with | elevated privileges. I have FEATURES=userpriv. Package foo has | RESTRICT=userpriv. I don't have ACCEPT_RESTRICT=userpriv. When I | try to install package foo, it fails, because I don't want to allow | RESTRICT=userpriv. Bogus argument. If an ebuild were truly doing something naughty with elevated privs, it could just do it in one of the pkg_ phases. Since userpriv isn't a security feature, there's no advantage for the end user in restricting based upon it. So again, which RESTRICT variables should the user legitimately have to care about? -- 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] [RFC] Ideas for projects...
The Gentoo Council is looking for some ideas for some small projects that we could initiate that would help Gentoo. These project ideas should be things that are attainable in a measurable amount of time, and should be fairly small in scope. This would be in the same vein as the Google Summer of Code projects. Robin Johnson came up with a good example, which was genflags an application that was to gather information from the running system and spit out a customized set of C(XX)FLAGS for the user. 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. Thanks in advance! -- 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] Ideas for projects...
Chris Gianelloni wrote: The Gentoo Council is looking for some ideas for some small projects that we could initiate that would help Gentoo. These project ideas should be things that are attainable in a measurable amount of time, and should be fairly small in scope. This would be in the same vein as the Google Summer of Code projects. Robin Johnson came up with a good example, which was genflags an application that was to gather information from the running system and spit out a customized set of C(XX)FLAGS for the user. 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. Thanks in advance! RSS feeds for packages added and removed from the tree with potential support for external overlays? I can see a file like debian's sources.list for the external ones with the addresses like this: #Add external overlay addresses here: http://dev.gentooexperimental.org/pkgcore-trac http://overlays.gentoo.org/proj/mysql/ http://overlays.gentoo.org/proj/java/ George -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On Thu, Jan 11, 2007 at 04:04:31PM -0500, Chris Gianelloni wrote: Robin Johnson came up with a good example, which was genflags an application that was to gather information from the running system and spit out a customized set of C(XX)FLAGS for the user. I should clarify, that genflags was a short project based on requirements from Daniel Robbins. I wrote it in mid-2003. The old code (app-portage/genflags) is still in the tree, but has badly stagnated (not updated since GCC3.3, and it was before the widespread entry of amd64 machines). -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgphzRsY3KIsK.pgp Description: PGP signature
[gentoo-dev] [RFC] Some sync control
Hello, After yesterday epkgmove fun I thought that it would be nice to have some control on when our cvstree is synced with mirrors. My first very basic idea is just to put a block_sync file in the tree when smth big is going on, like new kde version stabilization or big pkg move. Inside the file we could have smth like user - why - until timedate. What do you think? -- Best Regards, Piotr Jaroszyński -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
maillog: 11/01/2007-17:02:48(+): Ciaran McCreesh types On Thu, 11 Jan 2007 11:56:09 -0500 Mike Frysinger [EMAIL PROTECTED] wrote: | On Wednesday 10 January 2007 20:01, Ciaran McCreesh wrote: | On Wed, 10 Jan 2007 19:56:00 -0500 Mike Frysinger | [EMAIL PROTECTED] | | as stated in original e-mail, unattended/sandbox are just some | | examples, not the only ones | | So which RESTRICT values *should* the user legitimately have to care | about? | | On Wednesday 10 January 2007 16:40, Chris Gianelloni wrote: | I am a user. I don't want any of my compiles executing with | elevated privileges. I have FEATURES=userpriv. Package foo has | RESTRICT=userpriv. I don't have ACCEPT_RESTRICT=userpriv. When I | try to install package foo, it fails, because I don't want to allow | RESTRICT=userpriv. Bogus argument. If an ebuild were truly doing something naughty with elevated privs, it could just do it in one of the pkg_ phases. Since userpriv isn't a security feature, there's no advantage for the end user in restricting based upon it. So again, which RESTRICT variables should the user legitimately have to care about? I agree that if an ebuild wants to misbehave it can and there is no stopping it. However, code that is executed in pkg_* is generally restricted to code written by the person who is involved in maintaining the ebuild. It is easy to read that code and see what it does. In contrast, the stuff that is run with lowered privileges is usually coded upstream. I'd like to have that run with lowered privileges, no matter what. -- / Georgi Georgiev/ As in certain cults it is possible to kill / \ [EMAIL PROTECTED]\ a process if you know its true name. --\ / http://www.gg3.net/ / Ken Thompson and Dennis M. Ritchie / pgpJyKmnbFmRj.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Some sync control
Piotr Jaroszyński kirjoitti: Hello, After yesterday epkgmove fun I thought that it would be nice to have some control on when our cvstree is synced with mirrors. My first very basic idea is just to put a block_sync file in the tree when smth big is going on, like new kde version stabilization or big pkg move. Inside the file we could have smth like user - why - until timedate. What do you think? Been wanting / talking about something like this for a while :) Regards, Petteri signature.asc Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Some sync control
Piotr Jaroszyński wrote: What do you think? I think it would be much nicer to have a VCS with support for atomic commits. -- Kind Regards, Simon Stelling Gentoo/AMD64 Developer -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
On Thu, Jan 11, 2007 at 10:29:58PM +0100, Piotr Jaroszy??ski wrote: After yesterday epkgmove fun I thought that it would be nice to have some control on when our cvstree is synced with mirrors. My first very basic idea is just to put a block_sync file in the tree when smth big is going on, like new kde version stabilization or big pkg move. Inside the file we could have smth like user - why - until timedate. If you'd asked the infra folks, in the past we have just blocked it when people asked us to. However I do really like the idea of moving the control towards developers, and I'll take the first step of strongly defining the format of the file. 0. File location is located at profiles/block_sync 1. Lines starting with a # are comments. 2. Each entry must be separated by one or more lines of whitespace. 3. Each entry based on RFC[2]822 format, with continuation lines if needed. This makes parsing very easy. (See people complaining about trying to parse comments in package.mask lately). 4. The following headers must be included: Entry-Date, Start-Date, Signed-Off-By, Reason. 5. All dates must be in UTC and conform to RFC2822. (Use 'date -R -u' output) 6. Start-Date specifies when the block starts. Entry-Date is when the entry was created in the file. 7. Signed-Off-By must be the contact person for the block. More than one Signed-Off-By line may be present. 8. The following headers are optional: Completion-Date, References 9. References should include links or message-ID numbers to publicly visible reasons as to why the block is in place. 10. A Completion-Date may be present, but is a guideline only. No automatic action shall be taken based on this line. 11. Other headers may exist, and should not interfere with the file. Example entry: == Entry-Date: Thu, 11 Jan 2007 21:45:23 + Start-Date: Thu, 11 Jan 2007 22:00:00 + Completion-Date: Thu, 11 Jan 2007 23:00:00 + Signed-off-By: Robin H. Johnson [EMAIL PROTECTED] References: http://article.gmane.org/gmane.linux.gentoo.devel/45310 Reason: The following is an example of a block for the block_sync file. This is a continuation line. Notice the leading space. It is still part of the Reason header. # The above is the example block == -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpgECCyrwU27.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Some sync control
On Thu, Jan 11, 2007 at 11:49:43PM +0200, Simon Stelling wrote: Piotr Jaroszy??ski wrote: What do you think? I think it would be much nicer to have a VCS with support for atomic commits. I agre, from multiple points of view including those of 1. developer who has broken stuff with epkgmove, 2. developer who has broken things moving by hand 3. CVS administrator, 4. general infra. However, for several reasons this is not yet feasible, and furthermore purely atomic commits will not negate the need for the block_sync functionality. Tree breakage has been noticed in the past, and infra has been asked to block the rsync process until the breakage was fixed. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpaVWKy1june.pgp Description: PGP signature
Re: [gentoo-dev] [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. Construction of a dynamic website for tracking kernel security issues. There are too many of them and too many kernels to do this through the normal GLSA process, and currently users are kept in the dark about fixed security issues. Tim had started developing a site for this (KISS) but it was never finished and had the large downside that it relies upon an operator duplicating lots of information from bugzilla and the ebuild tree into KISS. Such a system would be able to automatically pull a large proportion of the required information relatively easily. It would offer functionality to allow users to sign up for security announcements and fixes for their kernel(s) of choice, as well as feeding the same info into a mailing list for all kernels. Daniel -- gentoo-dev@gentoo.org mailing list
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
RE: [gentoo-dev] [RFC] Ideas for projects...
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. Maybe GLEP 42 could be the pilot. :-) 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 -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
On Thu, 2007-01-11 at 14:08 -0800, Robin H. Johnson wrote: However, for several reasons this is not yet feasible, and furthermore Just for the sake of completeness can you outline those reasons? Thanks, -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
On Thu, Jan 11, 2007 at 05:51:43PM -0500, Seemant Kulleen wrote: On Thu, 2007-01-11 at 14:08 -0800, Robin H. Johnson wrote: However, for several reasons this is not yet feasible, and furthermore Just for the sake of completeness can you outline those reasons? I'm not saying it won't happen ever, just not yet. 1. The work-in-progress for planning out the migration to the new CVS/SVN box at GNi. The new hardware will be needed regardless of which VCS we will need. 2. See the results (and as-yet unpublished GLEP) of Antarus's Summer of Code research into VCS migrations. I'll include his summary verbatim here: If Gentoo is to switch now I could only recommend SVN. GIT needs just those few extra features to be a viable canidate. I think if there are volunteers to make GIT work for Gentoo than that would be best. GIT is a better all around tool in terms of technical merits for most development tasks. The upstream GIT developers have started work on some of these changes, as they need them (see the recent scaling problems with gitweb on kernel.org). GIT has improved in the 6 months since Antarus's SoC work was done. 3. In regards to any possible migration, the point of infra is that it is not acceptable to migration to $X now, and then $Y 6 months down the road. Reasons behind this are concerns over loss of data in repeated migrations, and having to revisit various scripts and tools more than otherwise necessary. My personal view (not infra) on it, is that I'm mostly negative about changing VCS at all - I would prefer not to change, because the status quo works very well as it is. If a change is going to be made, it should be taken as a chance to resolve as many different issues at one time as possible, and for that reason I favour GIT over SVN. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgpcZAeOdZuz9.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
Simon Stelling wrote: I like the idea. Something really useful I could think of is *drums* the implementation of GLEP 42. GLEP 42 is almost fully implemented and is currently undergoing local testing (by me) to find the last of the obvious bugs. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
Seemant Kulleen wrote: On Thu, 2007-01-11 at 14:08 -0800, Robin H. Johnson wrote: However, for several reasons this is not yet feasible, and furthermore Just for the sake of completeness can you outline those reasons? Thanks, The status quo is a harsh mistress. 'There is no compelling reason to switch systems'. If we were starting anew? SVN in a heartbeat. But we have 6 years of cvs experience, and it works...fairly well as you know. The primary reasons for svn are better local support for stuff (read diffs), atomic commits, and file moves. Branching..I don't think is really useful for gentoo-x86 as it doesn't fit the style of how we do things. GIT is a good alternative, but has massive changes of it's own, particularly I think in workflow. Workflow is important, and it's beneficial to make the workflow changes at the same time as the backend is changed. -Alec Warner -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
GIT is a good alternative, but has massive changes of it's own, particularly I think in workflow. Workflow is important, and it's beneficial to make the workflow changes at the same time as the backend is changed. Alec, Can you speak to some of these workflow changes? I only have experience with cvs and svn, not git or bzr or any of the other stuff that's out there, so I honestly do not know what their models and workflows are. So from my own uneducated stance, svn wouldn't be a workflow issue at all for most things, no? Thanks, -- Seemant Kulleen Developer, Gentoo Linux -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Some sync control
Seemant Kulleen wrote: GIT is a good alternative, but has massive changes of it's own, particularly I think in workflow. Workflow is important, and it's beneficial to make the workflow changes at the same time as the backend is changed. Alec, Can you speak to some of these workflow changes? In cvs and svn you have people working on their local copy and then commit things on the remote server. In distributed systems everybody has his local history (full?) and you can push or pull for every repo (that are peers in this case) as you wish, so you could implement different workflows since you have many more degrees of liberty. See http://www.kernel.org/pub/software/scm/git/docs/tutorial.html and the other docs to have some examples of workflows. lu -- Luca Barbato Gentoo/linux Gentoo/PPC http://dev.gentoo.org/~lu_zero -- gentoo-dev@gentoo.org mailing list
[gentoo-dev] Council Meeting Log and Summary for 11th January 2006
See attached. -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 Summary of the Gentoo Council meeting held 11 January 2006 -- (Summary prepared by robbat2). Roll-call: Present: flameeyes (proxied by UberLord), kingtaco, kloeri, kugelfang, robbat2, wolf31o2 Absent: vapier No agenda items were raised ahead of time, so we just went in alphabetical order. - Kugelfang reported that the EAPI0 draft document is not quite complete. spb had hoped to have it ready before the meeting, but didn't manage. It has been restricted thus far to avoid 'large discussions about minor details' while the bigger picture is assembled. It will be open for all input and refinements later. - Kugelfang visited the issue of the contents of /usr/libexec. Diego and Vapier had raised it previously, and Kugelfang is working on the document, in a style similar to FHS. - Kugelfang wanted to know about the process for council members stepping down. This was prompted by solely by Flameeye's message to the council channel earlier in the day, which implied he was retiring. The point was made moot by Flameeye's later blog post that he was going to take a two week break instead. - On the procedural side, both Kugelfang and KingTaco wanted to know what the what the process for a retiring council member was. Should it be the next person on the original ballot results, or should a further election be held? The spirit of the council GLEP was a further election, but some questions were had in this. The issue needs to be raised on the -dev mailing list, and revisited during the next council meeting. - Robbat2 reported on the successful bugzilla migration, and the work for the new CVS server. The Bugzilla news was well recieved. - Robbat2 brought up the status of the SPF documentation. Kloeri said that he has them in a nearly finished state, but hasn't had a chance lately to complete them. Kloeri will other complete them shortly, or upload the drafts to the bug in the meantime. - Robbat2 requested that for helping to get an agenda together in future, all council members should just braindump their potential minor items to the council mailing list a few days ahead of each meeting. Large issues should still be raised on -dev/-core as needed, but the smaller stuff like followups can just be braindumped. Robbat2 promised to rig an automated reminder to the council members. - A last call for vapier was made, and since he didn't show, he got his slacker mark for this meeting. - Wolf31o2 inquired as to the status of the Reply-To documentation (bug 154595). As there was absolutely no progress, Wolf31o2 was going to just write it up and convert it to GuideXML. - Wolf31o2 proposed the concept of council-managed projects. These are to be Gentoo-specific projects where the council takes the initiative of defining creating software specifications and requirements, recruits people to work on them (not nessicarily developers), and helps manage the project (leaving people to actually work on it). Some past almost precedents were noted and the council was in favour of the general concept. Wolf31o2 was going to seek out some initial proposals for small projects to test the concept on. The floor was opened at this point. - KingTaco jokingly asked if the Gentoo Foundation could afford to buy Sealand, which lead into real queries about the current financial reports. Wolf31o2 located a November 2006 posting in the NFP archives and provided a link to it. Jan 11 12:00:09 wolf31o2|mobile heh Jan 11 12:00:17 * robbat2 sets mode +m #gentoo-council Jan 11 12:00:56 robbat2 ok, it's time folks Jan 11 12:00:57 kingtaco|work roll-call Jan 11 12:01:01 * kingtaco|work is here Jan 11 12:01:11 kloeri hi all Jan 11 12:01:29 * wolf31o2|mobile is here Jan 11 12:01:32 robbat2 Kugelfang, SpanKY, vapier: pingy Jan 11 12:01:42 kingtaco|work no uberlord? Jan 11 12:01:45 kingtaco|work for flameeyes? Jan 11 12:01:49 * You've invited UberLord to #gentoo-council (zelazny.freenode.net) Jan 11 12:02:10 * iluxa ([EMAIL PROTECTED]/developer/iluxa) has joined #gentoo-council Jan 11 12:02:13 * You've invited Uber to #gentoo-council (zelazny.freenode.net) Jan 11 12:02:20 * antarus ([EMAIL PROTECTED]/developer/antarus) has joined #gentoo-council Jan 11 12:02:32 * kingtaco|work has changed the topic to: Next meeting: NOW Jan 11 12:02:40 Kugelfang orly? Jan 11 12:03:16 kingtaco|work 5 of 7 Jan 11 12:03:31 kingtaco|work lets get the shindig started Jan 11 12:03:33 * DrEeevil ([EMAIL PROTECTED]/user/bonsaikitten) has joined #gentoo-council Jan 11 12:03:42 robbat2 anybody got an Agenda? I didn't see one posted Jan 11 12:03:50 kingtaco|work I don't Jan 11 12:03:59 Kugelfang robbat2: i have two thingsw Jan
Re: [gentoo-dev] [RFC] Ideas for projects...
On 1/11/07, Chris Gianelloni [EMAIL PROTECTED] wrote: The Gentoo Council is looking for some ideas for some small projects that we could initiate that would help Gentoo. My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] Ideas for projects...
On Friday 12 January 2007 05:43, Richard Fish wrote: My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. app-portage/eix already does a lot of this with --test-non-matching and --test-obsolete. -- Bo Andresen pgpxLeKmkecCN.pgp Description: PGP signature
Re: [gentoo-dev] [RFC] Ideas for projects...
On 1/11/07, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: On Friday 12 January 2007 05:43, Richard Fish wrote: My idea would be to extend emaint to check package.keywords and package.use for obsolete flags, unnecessary atoms (like foo-1.2 in keywords when foo-1.3 is stable), atoms that don't match any current ebuild, and so on. app-portage/eix already does a lot of this... Sigh. I can't keep up with these changesnevermind :-( -Richard -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-dev] [RFC] ACCEPT_RESTRICT for questionable values of RESTRICT
On Fri, 12 Jan 2007 06:38:23 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | I agree that if an ebuild wants to misbehave it can and there is no | stopping it. However, code that is executed in pkg_* is generally | restricted to code written by the person who is involved in | maintaining the ebuild. It is easy to read that code and see what it | does. In contrast, the stuff that is run with lowered privileges is | usually coded upstream. I'd like to have that run with lowered | privileges, no matter what. So you trust upstream to install arbitrary content on your computer, some of which may not be removed even when you uninstall the package, but you don't trust the package to compile with elevated privs, even when a Gentoo developer has carefully checked why userpriv is required? -- 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 06:38:23 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | I agree that if an ebuild wants to misbehave it can and there is no | stopping it. However, code that is executed in pkg_* is generally | restricted to code written by the person who is involved in | maintaining the ebuild. It is easy to read that code and see what it | does. In contrast, the stuff that is run with lowered privileges is | usually coded upstream. I'd like to have that run with lowered | privileges, no matter what. So you trust upstream to install arbitrary content on your computer, some of which may not be removed even when you uninstall the package, but you don't trust the package to compile with elevated privs, even when a Gentoo developer has carefully checked why userpriv is required? Why would it not be removed? Upstream installs in the sandbox, the contents of the sandbox are recorded in the package database and with collision-protect it will not override random stuff on my computer. If I uninstall the package without ever touching it, everything will be removed. I do exclude the pkg_* phases from the above, but we already agreed that nothing from upstream executes there. 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. 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 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, and whether or not one should trust a build system that won't work with userpriv. If you don't trust the build system with non-userpriv, you shouldn't trust it at all. -- 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, 12 Jan 2007 16:02:01 +0900 Georgi Georgiev [EMAIL PROTECTED] wrote: | Why would it not be removed? Upstream installs in the sandbox, the | contents of the sandbox are recorded in the package database and | with collision-protect it will not override random stuff on my | computer. Unless upstream decides to override the sandbox sneakily, or uses one of the many tricks to get content onto the live filesystem that Portage won't handle. | If I uninstall the package without ever touching it, | everything will be removed. I do exclude the pkg_* phases from the | above, but we already agreed that nothing from upstream executes | there. Not true. Not in the sliightest bit true. There are approximately three zillion quirks in how Portage handles the merge which would allow one to slip something through the cracks. Examples include overwriting directories with files and installing non-(directories|symlinks|files). Or if you want examples that will also work with package managers that are more secure than Portage, think installing cron.d entries to create malicious content. | 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. -- 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 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. -- gentoo-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Masked by corruption
On 02.01.2007, at 06:56, Zac Medico wrote: In =portage-2.1.2_rc4-r2 t does that now for installed package (see bug #158931). For /var/cache/edb/dep the sqlite module is available (requires pysqlite or python-2.5 with sqlite support enabled). Where can i find documentation about this? I use metadata-transfer at the moment, but all info i got was from the examples-section in man emerge and from the forum. Is there some official complete list of theese modules with some description? Thanks, Philipp -- gentoo-portage-dev@gentoo.org mailing list
Re: [gentoo-portage-dev] Masked by corruption
On Fri, Jan 12, 2007 at 12:18:34AM +0200, Philipp Riegger wrote: On 02.01.2007, at 06:56, Zac Medico wrote: In =portage-2.1.2_rc4-r2 t does that now for installed package (see bug #158931). For /var/cache/edb/dep the sqlite module is available (requires pysqlite or python-2.5 with sqlite support enabled). Where can i find documentation about this? I use metadata-transfer at the moment, but all info i got was from the examples-section in man emerge and from the forum. Is there some official complete list of theese modules with some description? The portage can probably answer better than I can, but here's a quick hack. grep 'class database' -rl /usr/lib/portage/pym/cache/ -- Robin Hugh Johnson Gentoo Linux Developer E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85 pgplwrZfNf3z7.pgp Description: PGP signature
Re: [gentoo-portage-dev] Masked by corruption
On 1/12/07, Philipp Riegger [EMAIL PROTECTED] wrote: Where can i find documentation about this? I use metadata-transfer at the moment, but all info i got was from the examples-section in man emerge and from the forum. Is there some official complete list of theese modules with some description? http://gentoo-wiki.com/TIP_speed_up_portage_with_sqlite With a ruby script written by myself which does quick reverse dependancy lookups using that SQLite. ( portage still doesnt seem to utilize the SQLite database for that capacity :/ ) -- gentoo-portage-dev@gentoo.org mailing list
