On Fri, 2006-06-09 at 00:30 +0200, Markus Ullmann wrote: > > I know that when I spoke of security, I was not only talking about the > > security of letting non-developers commit to an overlay that is, by > > design, for end users, but also of the implications of ensuring that any > > packages in these overlays are not vulnerable to exploits. > > You're right here, there is a chance that your system gets vulnerable. > But this isn't limited to this one overlay. All overlays are affected here.
Not like you think that they are. Let me try to make this clearer. The php overlay is maintained by the php developers. They are intimately aware of the issues with their package, and are probably aware of any security bugs before the rest of us. You are talking about a random collection of ebuilds with absolutely no cohesiveness other than they were submitted to bugzilla. How are you going to maintain any form of security on this project? > >> 2) responsibility > >> > >> As already mentioned at 1), it is an overlay. The devs on sunrise do > >> keep an eye on it and all ebuilds do have to pass at least repoman and > >> some basic QA checks (currently done when porting them from bugs.g.o) so > >> that they don't do some rm -rf / thing. They should be improved by the > >> contributors then so that we have two things here: a) a contributor who > >> can contribute good-quality ebuils and b) a good ebuild to be picked up > >> by a dev and ported to the tree > > > > The problem is that you are only checking on the initial commit. Go > > back to point #1 (security). > > You just assume this, no real reason/example for it. No. It clearly says that you would be doing the basic QA checks and repoman checking on initial commit. You even said it right above where I commented! > > Honestly, having to break out a subversion client to check a fix > > immediately sounds like extra work. It is usually much easier to simply > > look at the attachment online and make a decision immediately. > > You don't need a subversion client, you perhaps notice the http in front > of the url.. just open it up in your browser and you get the source > immediately. Umm... so now I need to go and instead of clicking a nice link in bugzilla, trawl through the subversion repository and find what I'm looking for? How exactly is downloading things via http any different than downloading them from bugzilla, which is also http? Now, I know that you're not an idiot, so please don't treat me like one. > Or, if you want some history like sources.g.o, you can do so as well here: > http://overlays.gentoo.org/proj/sunrise/browser/ Excellent. So we're moving the history from being in a single location (the bug) to being in multiple locations. That will definitely improve the development process. Another thing that people tend to miss is that not all improved versions of ebuilds submitted to bugzilla are done byt he original authors. There are many cases where an initial ebuild is done, a developer makes comments on what needs to be changed, and *another* contributor gives a fixed ebuild. How exactly will this streamline that process? No offense, but everything I have seen looks as if it will add even *more* overhead to actually getting packages into the tree. The only thing this seems to provide is a half-baked repository for the users to get marginally-tested ebuilds for software that wasn't interesting enough for inclusion in the tree. > > Except that I can *look* at an ebuild without having to break out a > > subversion client currently. > See my answer in 3) See mine. ;] > > How exactly are they > > supposed to know that this user has pam_skey even *available* to them > > when all they see as an overlay is "sunrise" and not the > > project-specific overlays that overlays.gentoo.org was designed for? > > Well as the ebuilds in there already have open bugs, comments can be > attached there. This is a bug for an ebuild that the user does not think is related to the pam_skey. Go back and read what I wrote. > Secondly, the portage team already integrates a patch to show you a > bright warning in the error that you use an overlay... also, if you take > a look at the PORTDIR_OVERLAY in emerge --info, you can get really fast > that in case you don't find the ebuild in tree that it doesn't belong > there. (We even get bugs originating at other overlay's ebuils...) Again, read what I wrote. I said that the developer would see "sunrise" in the PORTDIR_OVERLAY of the user's emerge --info, which you reiterated without considering. This is a login bug. At no point did they make mention of having installed pam_skey from this overlay. This means that I, as the developer getting this bug, am now responsible for looking at *every package* in the sunrise overlay to determine if *any* of them could *possibly* be affecting this package or causing this bug, then asking the user if they have any of them installed. Wouldn't this process be *infinitely* easier if instead of "sunrise" there was a "pam" overlay with *only* the pam stuff? That is *exactly* what we get with the other overlays like php and vmware. I *know* that if I'm looking at a glibc bug and the user has "php" as an overlay, that it isn't going to be a concern. > > All of the time wasted to determine that the user has done something > > unsupported to break their system is time that this developer could be > > working on a problem with a package that is actually in the portage > > tree, which is our primary product. > > bug wranglers already do this job currently... They do this in a very quick and cursory manner. They do a pretty good job of it, but there are countless bugs which they do not catch that are not assigned properly or end up being invalid due to user negligence. The bug wranglers cannot be *expected* to perform this level of service, lest they burn out and run away within a couple weeks. ;] > > You miss something. Things in this overlay still don't make it into the > > official tree unless a maintainer picks it up. Taking an ebuild from > > bugzilla and being responsible for it and taking an ebuild from an > > overlay and being responsible for it have the exact same cost on > > developer resources. Someone *still* has to maintain it. > > Yup, but the proxy maintainerships are much easier to track as they're > done on one central place... This is a prime example of totally glossing over any discussion to make it sound promising for you. How exactly is a proxy maintainer going to know that a new version of an ebuild has been committed? Either by watching the overlay like a hawk, or when the maintainer emails/pings/whatever and lets him know that there's a new version. How exactly is this easier to track? Even better, if I am the proxy maintainer for a particular set of ebuilds for one or more user/maintainers, why do I need it in your big, bloated, and completely inappropriately-named "sunshine" overlay versus a developer overlay of my own? After all, I am the *only* proxy maintainer. Why should there be the added *insecurity* of allowing any number of people that *I* might not trust complete access to the small number of packages where I am the proxy? -- Chris Gianelloni Release Engineering - Strategic Lead x86 Architecture Team Games - Developer Gentoo Linux
signature.asc
Description: This is a digitally signed message part
