Created attachment 534734 [details] emerge --info Portage tries to verify manifests for excluded by rsync_excludes packages. !!! Manifest verification failed: Manifest mismatch for app-emacs/Manifest.gz __exists__: expected: True, have: False rsync_excludes contain a list of masks to exclude: app-emacs/* app-xemacs/*
You can disable verification with a setting like this in /etc/portage/repos.conf: [gentoo] sync-rsync-verify-metamanifest = no
*** Bug 659204 has been marked as a duplicate of this bug. ***
*** Bug 662828 has been marked as a duplicate of this bug. ***
Right. Apparently I filed a duplicate to this bug as I did not get a hit on my subject line. Must note that this particular subject line seems to indicate a user choice to set `USE=rsync-verify` where current portage appears to impose this setting and as posted by Zac can only be suppressed by changing the repos.conf. Yes I did find that workaround, but it seems to me that the rsync verify was added for a reason (the recent git hack?). What possible issues am I subjecting myself and my users to by following this advice?
any progress here? skipping removed directories during verification seem safe since it's removing attack surfaces...
(In reply to razamatan from comment #5) > any progress here? skipping removed directories during verification seem > safe since it's removing attack surfaces... It could be used as a means for an attacker to block security updates on your system.
(In reply to Zac Medico from comment #6) > (In reply to razamatan from comment #5) > > any progress here? skipping removed directories during verification seem > > safe since it's removing attack surfaces... > > It could be used as a means for an attacker to block security updates on > your system. that's assuming you've installed a package you've excluded? i guess i'm having a hard time coming up with a high likelihood scenario where a security update is blocked on packages you've *correctly* installed. even thinking about a new dependency that fixes a security bug, portage should complain that a dependency can't be fulfilled if the dep's directory isn't sync'd in. i would argue that the current workaround of USE=-rsync-verify or sync-rsync-verify-metamanifest=no is a much more dangerous exposure. i'm blocking [kde/qt]-* b/c i simply don't use anything there. i would bet that other people using the --exclude are also blocking app level things that they'll never use.
(In reply to razamatan from comment #7) > (In reply to Zac Medico from comment #6) > > (In reply to razamatan from comment #5) > > > any progress here? skipping removed directories during verification seem > > > safe since it's removing attack surfaces... > > > > It could be used as a means for an attacker to block security updates on > > your system. > > that's assuming you've installed a package you've excluded? No, the attacker would choose which package(s) to exclude. > i'm blocking [kde/qt]-* b/c i simply don't use anything there. i would bet > that other people using the --exclude are also blocking app level things > that they'll never use. It could be a lot of work to manage excludes that way.
I second that last comment by ramazatan. It is illogical to have an application installed that is part of the exclude list. Although granted, there is a tiny tiny chance that one could have an application that was moved within the tree. Also, if one does exclude a part of the tree intentionally they will empty it because if you don't that at some point will spell mayhem for dependency calculations. Subsequently portage will warn you if you have an application installed that is not in the tree because it cannot upgrade it nor depclean it. So with regard to the intermediate comment by Zac, it is impossible for an attacker that got access to the exclude list to get away without being detected. Skipping verification on empty dirs therefore does NOT affect security, needing to disable verification completely because of this obviously does. As for me, I maintain a Gentoo based OS for a headless system that consequently has no use for anything accessing local graphic resources because being headless the system has no hardware that supports it. X, desktop managers, games, all that stuff just needlessly uses (a lot of) time on low powered devices.
(In reply to Gordon Bos from comment #9) > Also, if one does exclude a part of the tree intentionally they will empty > it because if you don't that at some point will spell mayhem for dependency > calculations. Subsequently portage will warn you if you have an application > installed that is not in the tree because it cannot upgrade it nor depclean > it. So with regard to the intermediate comment by Zac, it is impossible for > an attacker that got access to the exclude list to get away without being > detected. Bug 654670 is relevant, you may not be aware of such packages.
As it happens I just had a bit of a situation with php on account of packages calling for USE flag `crypt`, causing it to pull in php 7.1 next to 7.2. No, that did most definitely not go unnoticed. Bug 654670 may be relevant to people that never do a depclean, but if you obey the instruction to do so after a world update then portage will inform you that it can't process packages for which no ebuilds exist and that you must delete those manually (i.e. by using emerge -C <package>)
(In reply to Gordon Bos from comment #11) > Bug 654670 may be relevant to people that never do a depclean, but if you > obey the instruction to do so after a world update then portage will inform > you that it can't process packages for which no ebuilds exist and that you > must delete those manually (i.e. by using emerge -C <package>) That message is only triggered when the installed package has one or more unsatisfied dependencies.
(In reply to Zac Medico from comment #8) > > i'm blocking [kde/qt]-* b/c i simply don't use anything there. i would bet > > that other people using the --exclude are also blocking app level things > > that they'll never use. > > It could be a lot of work to manage excludes that way. i'm actually using --exclude-from w/ an exclude file
@mgorny, how would you feel about having a gemato option for user excludes? (In reply to razamatan from comment #13) > (In reply to Zac Medico from comment #8) > > > i'm blocking [kde/qt]-* b/c i simply don't use anything there. i would bet > > > that other people using the --exclude are also blocking app level things > > > that they'll never use. > > > > It could be a lot of work to manage excludes that way. > > i'm actually using --exclude-from w/ an exclude file
User excludes were planned from the beginning. Sadly, I didn't have much time to look into them. I have this in my TODO now, and I'll try to find some time to implement the necessary API. Hopefully, it wouldn't be very hard given that it already supports excludes from Manifest file.
*** Bug 717096 has been marked as a duplicate of this bug. ***
any updates in the years since?