| Summary: | versions for eclasses needed | ||
|---|---|---|---|
| Product: | Portage Development | Reporter: | Alexander Holler <aholler> |
| Component: | Enhancement/Feature Requests | Assignee: | Portage team <dev-portage> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | carlo, r3pek |
| Priority: | High | ||
| Version: | 2.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alexander Holler
2003-08-07 01:20:30 UTC
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 |
