Created attachment 812860 [details] emerge --info I combined the desktop/gnome profile with the hardened (amd64) profile. net-print/hplip depends on net-dns/avahi[python] which internally depends on the use flag gdbm when the flag python is set. The gdbm flag is globally unset in the hardened profile, thus requires to be manually added again. Is it possible to add an exception to net-dns/avahi in the hardened profile so that the gdbm flag is not removed? Or should that be handled by the net-dns/avahi ebuild itself?
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5591d00f60e810160f78fa32a66fdbed591ddb7f commit 5591d00f60e810160f78fa32a66fdbed591ddb7f Author: Sam James <sam@gentoo.org> AuthorDate: 2022-09-20 00:01:35 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-20 00:02:10 +0000 profiles/features/hardened: drop odd USE defaults This leads to poor UX and there's no reason for hardened to deviate here -- none of these things make a system more hardened, they just lead to confusion. Closes: https://bugs.gentoo.org/871720 Bug: https://bugs.gentoo.org/831045 Signed-off-by: Sam James <sam@gentoo.org> profiles/features/hardened/make.defaults | 9 +-------- 1 file changed, 1 insertion(+), 8 deletions(-)
This really should have been fixed with an entry in one person's package.use. Now everyone on a hardened profile is pulling in berkdb, gdbm, and fortran, and rebuilding a ton of revdeps with support for mystery features. Having things off by default unless you need them is a pretty standard security practice.
(In reply to Michael Orlitzky from comment #2) > This really should have been fixed with an entry in one person's > package.use. I disagree. This has been a point of confusion for quite some time. > Now everyone on a hardened profile is pulling in berkdb, gdbm, berkdb is off by default now anyway. > and fortran, It's pretty common for something to end up needing Fortran and it has zero security impact. If you want to lobby for changing the base default, go ahead. > and rebuilding a ton of revdeps with support for mystery > features. All of it seems pretty well-defined to me. And I say this as a heavy hardened user. And the person doing all the work on the profiles at the moment. > Having things off by default unless you need them is a pretty > standard security practice. I suggest you propose in the appropriate venue a list of things you think should be disabled on hardened, as opposed to the previous case of negating defaults with dubious gain.
(In reply to Sam James from comment #3) > > > Now everyone on a hardened profile is pulling in berkdb, gdbm, > > berkdb is off by default now anyway. Having USE="-berkdb" in the hardened profile also used to override IUSE defaults, so any package with IUSE="+berkdb" will now toggle on. > > and rebuilding a ton of revdeps with support for mystery > > features. > > All of it seems pretty well-defined to me. And I say this as a heavy > hardened user. And the person doing all the work on the profiles at the > moment. I know you're doing a lot of work and I'm glad you usually just go ahead and fix things. I don't want to give you too hard of a time about this. What I meant by "mystery features" is that it's near impossible for a normal user to figure out what USE=berkdb, USE=gdbm, or USE=fortran actually *do* for a given package. There are no metadata.xml descriptions for global flags, and the ebuild usually isn't much help either: you'll probably just see e.g. $(use_enable gdbm). That means you have to go digging into the source of the upstream project to see what was just turned on, and repeat the chore for every package that uses one of those flags. > > Having things off by default unless you need them is a pretty > > standard security practice. > > I suggest you propose in the appropriate venue a list of things you think > should be disabled on hardened, as opposed to the previous case of negating > defaults with dubious gain. I think everything should be off by default in the base profile (and in IUSE, except in extreme cases). But as a compromise, we've had several of the more pointless base flags disabled on hardened for probably a decade now. I'm not going to start quoting policy at you, but if there was a time to discuss these things, it was before changing the profile in the first place.
(In reply to Michael Orlitzky from comment #4) > (In reply to Sam James from comment #3) > > > > > Now everyone on a hardened profile is pulling in berkdb, gdbm, > > > > berkdb is off by default now anyway. > > Having USE="-berkdb" in the hardened profile also used to override IUSE > defaults, so any package with IUSE="+berkdb" will now toggle on. > As part of the efforts in bug 837629, there should be very few of these left. But yes - flipping between +/-berkdb is a pain for the remaining ones (which is why they remain :() > > > > and rebuilding a ton of revdeps with support for mystery > > > features. > > > > All of it seems pretty well-defined to me. And I say this as a heavy > > hardened user. And the person doing all the work on the profiles at the > > moment. > > I know you're doing a lot of work and I'm glad you usually just go ahead and > fix things. I don't want to give you too hard of a time about this. > Thanks. > What I meant by "mystery features" is that it's near impossible for a normal > user to figure out what USE=berkdb, USE=gdbm, or USE=fortran actually *do* > for a given package. There are no metadata.xml descriptions for global > flags, and the ebuild usually isn't much help either: you'll probably just > see e.g. $(use_enable gdbm). That means you have to go digging into the > source of the upstream project to see what was just turned on, and repeat > the chore for every package that uses one of those flags. FWIW, the things in the base package set affected by this were pretty small. For Python, you don't really want to use the non-sqlite & non-gdbm fallback. It's grotty code which nobody ever tests. For Perl, a lot of applications assume either gdbm or berkdb, and berkdb breaks ABI to flip for Perl. But I agree that a lot of our USE descriptions could be waaaay better. I'm guilty of writing poor ones myself. "Enable support via $LIB" isn't _really_ helpful in learning what something does. > > > > > Having things off by default unless you need them is a pretty > > > standard security practice. > > > > I suggest you propose in the appropriate venue a list of things you think > > should be disabled on hardened, as opposed to the previous case of negating > > defaults with dubious gain. > > I think everything should be off by default in the base profile (and in > IUSE, except in extreme cases). But as a compromise, we've had several of > the more pointless base flags disabled on hardened for probably a decade > now. I'm not going to start quoting policy at you, but if there was a time > to discuss these things, it was before changing the profile in the first > place. Thanks, point taken, and I'll do that in future. All in all, I take your point, and I'm sorry for not communicating better. On balance, this was one that was better to discuss, but I was a bit miffed by the -cli thing from before because it's caused some unexpected hassle in the past. Thank you!
