Chris Gianelloni wrote: > 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? >
The approach is to get them maintained... But there is a chance that there'll be security bugs in it, I admit that. Once we know about it, we p.mask it as we have support for it in the overlay. I'm following most common vuln lists and run some automated scripts already on installed packages, should be easy to adapt them to search one other dir as well. >>>> 2) responsibility >>>> > > 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! You're doing some witch hunting here... I said we keep an eye on non-devs commits. > >>> 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? the key difference is that you only need one wget command to get a completely prepared dir to work on, no ebuild renaming manual files/ population needed. > Now, I know that you're not an idiot, so please don't treat me like one. Was really not the intention.. You keeped the svn requirement which is simply wrong. Needed to make that clear. >> 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. we want to encourage users to contribute and if they do good contributions in bugzilla they get commit access to the overlay. and then the workload is drastically reduced... >>> 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. > it was agreed upon that we don't keep extra bugzilla or whatever for all things on o.g.o but keep track of all issues within bugs.g.o. and btw, most work on "new" bugs is done by bug wranglers and not the common devs. So if they say the workload from it is too high, I'll take it as valid reason as they have to handle it. >> 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. why would a pam dev get this bug? as far as I know bug wranglers work, a check whether the ebuild is in tree is one of the first ones... So the chance that it really hits the pam dev is damn small... We're not the first large overlay project, there are other ones out there already and these "wrong" bugs aren't a new thing arising here... > Wouldn't this process be *infinitely* easier if instead of "sunrise" > there was a "pam" overlay with *only* the pam stuff? Then the pam devs are responsible for all the things with it. As it would surely be hosted on o.g.o then, we'll notice it and either shift all ebuilds we have in the sunrise tree over or do whatever is fine with pam devs. If they really dislike the m-w bugs out of their control, then a friendly note on irc, a friendly mail or whatever is enough and we won't touch things of them then... > 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. Well we don't keep ebuilds in there which have a maintainer in contrast to the php overlay. they may even keep newer versions of in-tree packages in their overlays. >>> 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. ;] Well a simple grep for "sunrise" in there will show the needed thing... And, sorry, if one or another bug slips through. Wranglers are humans as well and humans make mistakes. Also you can't expect them to know about all issues. But that is a bit off-topic here. Just a last note on it: the main bug wrangler is helping us as well as commiting so I guess he notices the problems with sunrise... >>> 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? Tracking: First we want people to get used to it. Adding some random features like automated email upon a special commit can be added easily with just two lines in the post-commit hook... Dev-Overlay: Well you're free to use the dev overlay for it. But if you keep it on the sunrise overlay, it (hopefully) gets more tested. Greetz, Jokey
signature.asc
Description: OpenPGP digital signature
