This is likely a duplicate submission (couldnt find it mentioned) but.... Given that alot of people dont like to upgrade mozilla (as an example) just because there was a relatively minor typo somewhere in the ebuild (a new -rX), it could help thins if there was a way to specify that a perticular ebuild was incrimented due to a security fix (be it upstream or in the ebuild somewhere). Granted, when its upstream its not an ebuild revision, but people might not want whatever (potentially minor) changes have happend since foo-1.1.1 and foo-1.1.1.1 (being slightly excessive here). So, since people who upgrade ebuilds generally know why it is being upgraded, it could be useful if there was a way to denote a version change as being security related. If you wanted to go overboard with it, you could specify an env in the ebuild such as UPDATE_TYPE or something which could relate to any number of categories. (security|feature enhancements|minor|bugfix|whatever)....I dont know really, havent thought that far into it, but my initial desire was to see something along the lines of: ================================================= funkymonkey portage # emerge -up world These are the packages that I would merge, in order. Calculating world dependencies ...done! [ebuild S ] sys-libs/pam-0.75-r7 to / ================================================= Where the pam upgrade's 'S' tag denotes that it is a security upgrade. Then you could always have "emerge --update=security world" and such.... So, thanks for your time, sorry for rambling etc..... -T
I agree 100% with you!!!!!!!!! I understand that gentoo gives you the ability to stay up to date at all times using portage and you therefore are less vulnerable but gentoo as far as I can see has no security system in place whatsoever. Where are the security announcements and which package to upgrade? Why should I run emerge rsync emerge --update world and update all my system files when all I want to get is the security updates? The problem I guess is getting fed down what actually needs to be updates. emerge --security-only rsync emerge --security-only --update world Basically I am sitting here day in day out wondering if my box is secure simply having no way to check or gain feedback from gentoo.org. mk
*** Bug 7924 has been marked as a duplicate of this bug. ***
I was going to add this idea as it's own bug but I think this is a close match. I have been using win2k at work and windows update is constantly requesting me to download security updates. I don't like this for 2 reasons: -they sometimes come with crappy EULA's that I don't like to blindly agree with. -they mostly request a reboot after the update. otherwise, it's a pretty good method. Both of these seem to be non-issues on Gentoo. For that reason I think it would be a good idea to emulate this functionality to some extent. I think a good method would be to incorporate the GLSA announcements into portage. A system that automatically lists your installed packages with outstanding GLSA's against them, does it someplace where normal users would see it, and gives instructions for how to remedy the situation would be optimal. If I could issue one command to emerge all of the GLSA packages as this bug suggests, that would be great. I am just suggesting that the security updated packages or their announcements be made more visible by integrating them with Portage.
I think we need to start encoding and tracking security vulnerability information in some way, so that users are informed when an installed package has a security vulnerability. Exactly how is still in the thinking stages....
*** Bug 13352 has been marked as a duplicate of this bug. ***
Sorry for the #13352 dupe... There is an ongoing thread on forums (http://forums.gentoo.org/viewtopic.php?t=16340) discussing different possible implementations of an easy security-only upgrade : - A specific package.mask (security.mask ?) listing packages with known security holes, and an "emerge security" feature that would compare installed packages with this security.mask and upgrade those necessary - A specific rsync that would get only security fixes ("emerge world" would bring the system up to date security-wise) - A security "flag" that could be set in a package so that an "emerge world --security" would get only security-related packages The last one corresponds to the current consensus here, but maybe the other two are easier to maintain / more powerful (though less open to other categories than security) - ThC
I think that package masks need to contain the reason for the mask. Like the KEYWORDS line in an ebuild could read: "x86=stable ppc=unstable sparc=insecure arm=broken bones=broken ..." This way we can inform a user why a package is masked, including it a package got masked out because of a GLSA. I can see there being other reasons for it being masked out as well though.
I think it could also be interesting with an additional "bugfix" category. That is, a fix that corrects some acknowledged bug (including security ones). Maybe a more general category system would be beneficial? I saw this suggestion over here: http://forums.gentoo.org/viewtopic.php?t=39169
Hi guys, I was wondering if anyone knew how far away this idea was from becoming real? Are there any project plans for Portage, so one can see when, if at all, ones feature idea is going to start being realized?
whatever the final implementation (emerge flag, emerge 'class', package mask), i think having some sort of an indication (or pointers to) as to the reasons for the security update would be good. (see also additional comment #3) In addition, the <number> of GLSAs in the 'queue' for the update for each package should be clearly marked. This will allow for cases when i do not want to update for one outstanding GLSA (perhaps because i deem that it does not apply to me, or i think that the conditions needed for a possible exploit are too far-out in my case, and i do not want to waste time compiling again..), but i might be interested to update for the second GLSA that comes along. Carrying on with this point (i hope this is not too much to ask), it might be good for portage to mark out new GLSAs since my last emerge --pretend security. ie. suppose i did an emerge -p security last week, and found a GLSA for package x-1.2, but did not wish to update. In the meantime, 2 new GLSAs come in for the package. When i next do an emerge -p security, portage could show me my 3 outstanding GLSAs, as well as remark "hey! 2 new GLSAs have come in since you last checked. These are..." Thanks for reading, and thinking over these points.
I'm going to start working on a very crude script for this functionality. Is there a central place I can get all the GLSA's issued ? Henti
I have a working script for that, but I'm also stuck that there seems to be no public GLSA repository (beside the forums). Another problem is that my script uses a xml form of a GLSA, but that could possibly solved with a converter script. In case someone is interested, the code, XML DTD and example file are available at http://gentoo.devel-net.org/glsa/ , I try to add some docs this weekend.
Created attachment 16162 [details] tarball contains app-admin/security package for PORTDIR_OVERLAY this is an ebuild, which creates dynamically DEPENDencies for security updates of the Gentoo system. In this example, two DEPENDencies are checked (nfs-utils and gnupg, which are the latest GLSAs) Just install it into your PORTDIR_OVERLAY and do an 'emerge -p security' to see, if your system needs security updates.
I must say I like Karsten:s suggestion very much. Makes it all very smooth without messing with the base portage system. Could be implemented tomorrow if the infrastructure for generating the ebuild from the GLSA:s existed. Now, if I understand correctly, all packages with security issues since the beginning of time must be listed in the ebuild. Could be quite long, but seems scriptable enough (for someone with a good list of GLSA:s available). Also the security ebuild revision number must be bumped, and old ebuilds must be removed from the portage tree.
Comment on attachment 16162 [details] tarball contains app-admin/security package for PORTDIR_OVERLAY Please do NOT use my attached ebuild, because it breaks the calculation of the dependencies cache of the portage tree. Thanks to Paul de Vrieze, who told me about the danger. We currently discuss the chance to change the behavior of emerge itself. Stay tuned ;-) Karsten
Of these solutions I've seen proposed here I think I have to say Marius Mauch comment #12 seems to show the most potential and looks as it would/could plugin rather easy with our existing system. What I think we need right now is somebody to propose what is called a GLEP (Gentoo Linux Enhancement Proposal) which would outline the process of how we should handle GLSAs internally. ----- Our current Policy ----- 1) Create a bug report 2) Post bug # and package-name to -core 3) If we want, commit a masked fixed package 4) Person responsible for GLSAs unmasks and send out a GLSA 24h after bug has been announced on -core. -------------------------------
status update: GLEP 14 was accepted and we're currently designing the framework for the new GLSA release process. portage-2.0.51 will include this in some form, either as a new "security" target/option or as an external tool.
Were are we on integration of this feature (I have no clue)? Basically, what needs be done? This is one of the final steps of glsa integration in my eyes, and should be 2.1 material.
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
*** Bug 127643 has been marked as a duplicate of this bug. ***