Yet another fairly long message on the portage system. :-) 1. There should be a way of flagging packages as bad/dangerous in such a way that the end user is informed. Removing or masking a package from the /usr/portage-tree does not help the people that have already installed this package, they're just as vulnerable as before. The best way (off the top of my head) would be to list them in the output of "emerge --pretend --update world" (since that's the command most people use to stay up to date) and perhaps even automagically remove them on the actual update. Hm, no, not automatically, just let people know that they should remove it since there are scenarios where it might be okay to run a certain package. I'm not saying every removed package should get this treatment automatically, just the flagged ones. There are several reasons for a package to be masked/removed, but I'm right now considering this from a security point of view. Case in question right now is the fakeidentd-package, which has been simply masked off since at that point there was no newer source available (is now). The old package (1.4something) has a remote exploit, and just masking this will not remove that remote exploit from all the machines that have this package installed. In such a case I would feel safer if the system managed to inform me that I have a potentially dangerous package installed. 2. Another problem with masked packages is that they do not show up on "emerge search ...". There seems to be very little consistency in where a masked package is actually visible. Output from some emerge-options (or was that qpkg) will show it as [masked], but other options will not show the package at all. I was trying to find out the version number of my fakeidentd package (since 1.5 is safe), but since it was masked it didn't appear. This might have tricked me into believing that it wasn't installed, but I knew it was installed (and the process was running :-). This is the point where one of you point out to me that I should have used command Y (qpkg/epm/whatever) and where I counter with the fact that I really don't care if I can get the info some other way, it should all be consistent. :-) I would like "emerge search" to return masked, unmasked and installed packages (all versions), preferrably with different colouring to easily tell them apart. 3. When a package is unmerged, it's not shut down. It's definitively not right to kill processes every time a package is removed, but in some intances it is. Perhaps something as trivial as "is this the only installed instance of this package on the system, then kill it". Current unmerge system could potentially leave lots of non-installed software running still. Needs a bit of thought. 4. Quick question on the side here, almost nothing to do with the above. What is considered the best way of masking packages long term yourself? Editing /usr/portage/profiles/package.mask doesn't seem right, as it's constantly overwritten by rsync. What I'm looking for is some file I can hardwire package versions in, in such a way that I can be very sure that the package versions I decide upon will not change even tho I do an "emerge --update world" to upgrade the packages I'm not too concerned about. Perhaps even to the point where every single package on the system is explicitly named (with an "approved" version) in this file. This is a must if we're to consider gentoo for production systems.
comment #2 is invalid ... it was valid in older versions of portage, but hasnt been since 2.0.13 (maybe earlier, i dont remember) vapier root # emerge -s setiathome [ Results for search key : setiathome ] [ Applications found : 1 ] * app-sci/setiathome [ Masked ] comment #3 is a pretty nice concept, but in reality i dont think it would work for everything. it would work for /etc/init.d/ scripts (assuming the user started the service through rc scripts), but it wouldnt work for applications the user runs themselves. i guess if you wanted you go walk through /proc/# to check the exe file (`cat /proc/1/exe`) to see if its running, but thats kind of a pain :) as for comment #4, portage 2.0.22 (released today/yesterday) allows for this ... emerge it and check out the displayed message after its run, or read the file /var/db/pkg/sys-apps/portage-2.0.22/portage-2.0.22.ebuild
Re Point #4 in comment #1: People seem to forget you can "pin" packages in your /var/cache/edb/world file (or you used to be able to, hopefully that hasn't been taken out of portage). You simply specify the full category/package-version like so: =sys-kernel/gentoo-sources-2.4.19-r5 Then your gentoo-sources will always stay at 2.4.19-r5. Troy.
Well, #2 seems to be back again. root# emerge --version Portage 2.0.23 root# emerge -s setiathome Searching... [ Results for search key : setiathome ] [ Applications found : 1 ] root#
A small sugestion to make everything a bit easier... What about creating a /etc/portage/unmask file that allows users to allow specific packages to be unmasked, ignoring all testing flags and /usr/portage/profiles/packages.mask. For example: I use Grub 0.92 because I prefer that my Grub passwords be stored in md5 rather than clear-text. I do not want to allow all testing packages to be installed, because my system has to be reasonably stable. However, every time I rsync, the 'x86' arch is replaced with '~x86', which will cause all 'emerge --update's to downgrade to Grub 0.90. With /etc/portage/packages.unmask, I could add the line: =sys-apps/grub-0.92-r1 to allow Grub 0.92 to be kept instead of downgrading.
*** Bug 12651 has been marked as a duplicate of this bug. ***
*** Bug 34778 has been marked as a duplicate of this bug. ***
I ran across this when searching through some bug reports... Can this be closed? It looks like most if not all of this stuff has been resolved with /etc/portage and the other portage improvements... I think stopping services on unmerge has been discussed before many times on gentoo-dev and is generally considered WONTFIX, but that's just the impression i've gotten.
no, point #1 is very important to the security team we need a way to inform users that certain versions of packages on their system need to be upgraded ... and in the case of when a security fix hasnt been released yet, we need to inform them asap that there are issues with the package and they should take precautions until a fix is available or perhaps we should close this bug and open a new one requesting this 'security.mask' file
An alternative hack in the meantime is adding a pkg_setup() warning and sleep.
that hack isnt sufficient because it doesnt take care of the very important case of user already having said software installed
5 points to spanky.
Re commtnet #8 "or perhaps we should close this bug and open a new one requesting this 'security.mask' file" I'd vote for that idea myself.
ok, everything else here has been handled (specifically i know #2 and #4 are fixed) #3 is persued in some other Bug(s) creating a new one for #1
Regarding comment #9, When performing a new install or a significant upgrade, starting from about 10 seconds after emerge finishes finding the dependencies and starts working, I'm gone. Printing a warning and sleeping does not work. Regarding comment #13, And the new bug id is? Might have been considered a friendly idea to mention that it's 42355, so those of us interested in that aspect could switch bugs. (Yes, I'm aware that this isn't common practice. However, IMHO, it should be.)
