Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 5835 - New --pretend indicator for security
Summary: New --pretend indicator for security
Status: RESOLVED LATER
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core (show other bugs)
Hardware: All Linux
: High enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
: 7924 13352 127643 (view as bug list)
Depends on: 32803
Blocks: 2765
  Show dependency tree
 
Reported: 2002-07-31 20:51 UTC by Tom von Schwerdtner
Modified: 2011-10-30 22:38 UTC (History)
19 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
tarball contains app-admin/security package for PORTDIR_OVERLAY (security_ebuild_proposal.tgz,1.05 KB, application/octet-stream)
2003-08-16 02:28 UTC, Karsten Schulz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tom von Schwerdtner 2002-07-31 20:51:11 UTC
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
Comment 1 Marcel Kunath 2002-08-11 03:16:17 UTC
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
Comment 2 SpanKY gentoo-dev 2002-09-14 21:28:15 UTC
*** Bug 7924 has been marked as a duplicate of this bug. ***
Comment 3 Paul Oswald 2002-11-03 09:12:04 UTC
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.
Comment 4 Daniel Robbins (RETIRED) gentoo-dev 2002-12-09 13:37:00 UTC
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....
Comment 5 SpanKY gentoo-dev 2003-01-08 14:24:10 UTC
*** Bug 13352 has been marked as a duplicate of this bug. ***
Comment 6 Thierry Carrez (RETIRED) gentoo-dev 2003-01-09 02:43:30 UTC
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
Comment 7 Alain Penders (RETIRED) gentoo-dev 2003-02-02 12:20:53 UTC
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.
Comment 8 Per Cederberg 2003-03-05 05:23:10 UTC
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
Comment 9 klavs klavsen 2003-03-28 01:59:34 UTC
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?
Comment 10 Jeffrey Lim 2003-04-05 11:02:51 UTC
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. 
Comment 11 Henti Smith 2003-06-26 02:30:59 UTC
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 
Comment 12 Marius Mauch (RETIRED) gentoo-dev 2003-08-08 02:34:55 UTC
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.
Comment 13 Karsten Schulz 2003-08-16 02:28:32 UTC
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.
Comment 14 Per Cederberg 2003-08-16 03:41:48 UTC
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 15 Karsten Schulz 2003-08-16 09:02:54 UTC
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
Comment 16 solar (RETIRED) gentoo-dev 2003-08-16 16:04:28 UTC
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.
-------------------------------
Comment 17 Marius Mauch (RETIRED) gentoo-dev 2003-10-09 14:23:01 UTC
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.
Comment 18 Brian Harring (RETIRED) gentoo-dev 2005-02-27 21:45:41 UTC
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.
Comment 19 Jason Stubbs (RETIRED) gentoo-dev 2005-07-28 07:25:01 UTC
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. ;) 
Comment 20 Marius Mauch (RETIRED) gentoo-dev 2006-03-26 13:08:36 UTC
*** Bug 127643 has been marked as a duplicate of this bug. ***