Hi, I've stumpled over the fact, that there is almost no chance maintain an own portage tree where one can sure what's going on. One of the badiest things (imho) in the current portage design are those eclasses. I remember times where I find portage a good thing because writing ebuilds were something like writing a "configure; make; checkinstall;" script. Those ebuilds have been easy to understand and had almost no side effects. Since the use of eclasses that has changed dramatically. Ebuilds now using there own "language" and there using eclasses where no versions are available. E.g. I'm trying to maintain an "tested" subset of ebuilds where I only update ebuilds because of security issues. But there are those eclasses. Who tells me that an old ebuild builds cleanly with the current eclass the ebuilds uses? Nobody. Where are different versions of eclasses available? Only in the gentoo cvs. Where is a cross reference ebuild <-> eclass name and version available? Nowhere. So I have to hope that ebuild for app x.y works with the set of eclasses which are currently are in portage. This makes the current portage in my opinion more and more useless. It's nice if one will maintain a system where all programs are up to date (that's the only to chance have no problems because many others using the same "composition" of ebuilds), but it is almost impossible to maintain a stable system with changes only because of security reasons. After almost one and a half year using Gentoo/GNU Linux I've now almost at the point building a lfs with checkinstall (for easy removing of installed programs). I think this would cost me less time than I currently need to get a "stable, security fixed" system running under Gentoo/GNU Linux. Building a small database where dependencies of "install-scripts" aka ebuilds are kept shouldn't that hard using an normal db which is designed for data holding and retrieving (in contrast to the current portage where cross references are kept everywhere, in ebuilds, eclasses, portage itself and so on). Portage has changed it's outlook from a small, easy to use and easy to understand thing (for installing and removing programms from source) to a big, fat, hard to understand and hard to use thing (imho). Sorry for that criticism, first I've justed wanted to write a feature request for eclass versioning, but than all my opinions against those eclasses are now "wandered" into this bug. Just overread them, categorize this bug wontfixed and your bug statistic is clean as before (and one bug more is resolved). ;) Regards, Alexander Reproducible: Always Steps to Reproduce: 1. 2. 3.
Sorry for the bad english, I'm no "english native" and I've written that bug adhoc. And it's too hot here for reading all again to correct bugs. So I've choosed "wontfix" for the text. ;)
Just another comment, the eclass directory ist totally out of checksum control, so there's the almost the same exploit usable like for the files in the filesdir.
if you're worried about making sure your local ebuilds work with the eclasses, then i think PORTDIR_OVERLAY support for eclasses would be enough ... you could rename the eclass to eutils-1.eclass and inherit that, then put it in your local portdir and call it a day thats really the only issue i see in your bug report ... making sure your local ebuilds work with the eclasses ... and eclasses in portdir overlay would take care of it
I'm not worried about my own ebuilds, there not using eclasses. But I have had problems building old ebuilds with new eclasses and otherwise. Many new ebuilds did'nt work with old eclasses, so I have to update the eclasses. Then I got the problem, that some old ebuilds won't work with the new eclasses, so I have to update them. This tends to a system where I allways have to update all, which i find very bad. And what's with security issues? Without versions, writing a GLSA e.g. for kernel.eclass is a little annoying, as no one could verify if it's kernel has been build with the right eclass. This applies to all ebuilds who use eclasses as "includes".
I'm not worried about my own ebuilds, there not using eclasses. But I have had problems building old ebuilds with new eclasses and otherwise. arent these 2 statements contradicting each other ? either you're using eclasses or you're not ... and if an ebuild in the portage tree doesnt play well with an eclass that it inherits, well thats a bug that needs to be fixed ... as for GLSA's vs eclasses, thats another bug ... specifically, saving the eclass in the local /var/db/pkg/ directory along with the ebuild
I'm talking about old ebuilds which where sometimes in portage. I don't want to use every new version available in portage, because I don't want and don't have the time to test them every time a new version is available. It's nonesens to update every programm on a production system. E.g. I've just had a problem to emerge vim-6.1-r21 on an updated portage with new eclasses. Reason? The old ebuild fails and the ebuild for vim-6.1-r21 has changed in portage. So I have to update the ebuild for vim-6.1-r21 to that ebuild for 6.1-r21 which is currently in portage. Also the version is the same, I now have to check if the ebuild and new vim still works. Because this needs the same time as testing the actual version (6.2) I will now use vim-6.2. This are the things wich are contraproductive for managing a "stable" portage tree.
Versioning eclasses is a very simple solution to this. something-1.2.3.eclass Portage is only concerned with what comes before the '.eclass' part.
so in other words we'll leave it up to the individual developer/maintainer of an eclass ...
yes
The problem still exists. I will give it another try, hoping that someone has learned something in the past year. ;)
nothing is going to happen [still]
Ok, then you will find in the near feature another exploit for gentoo's portage in one of the ml's.
great, i hope it runs `rm -rf /` on my machine any other unrelated input ? i say we mark this a dupe of the 'portage fails to unmerge correctly when old eclasses have been removed' and call it a day
I haven't closed this bug which describes a vital security problem of portage. And now you want to close this bug again. You are very concerned about the user. But if you want to discuss this on ml's it's your point of view.
PS: If you like stupid things like rm -rf / you should reenter school (if you've already left them). I won't play 'script kiddie'. So much to unrelated input.
we can flame each other all we want but it still doesnt change the 'bug' the request is for 'eclass versions' ... this is not a portage bug each eclass is maintained completely by developers themselves sep from portage i, for example, maintain several eclasses if you want 'versioned eclasses', you're going to have to convince those eclass maintainers (and i know i for one am not going to go through the hassle of trying to maintain this kind of stuff) you want stability/etc..., join the gentoo server/stable project you want security, help with the eclass manifest signing either way, this bug in and of itself isnt going to happen
I won't trying a flamewar with you. I even won't to talk with you. It's seems just to be my destiny that you are almost every time the one who means he must give a (..) comment. In fact you are one of the reasons I think Gentoo will never reach any 'stable point', not as long as you are one of the first persons people are getting in contact with (through bugzilla). You are my favorite blocker/WORKSFORME/WONTFIX.
hi.... i just want to know why was this bug marked as WONTFIX? isn't security a consern of gentoo? why there is the GLSA then? why are we trying to mantain security in other packages when the postage itself has an exploit.... can't understand that :/ just my $0.02
no, if you read the security threads you would understand that versioned eclasses HAVE NOTHING TO DO WITH SECURITY what you want is Bug 64258
