<br></div><div> ScottE</div></div></div>
I'd like to focus on the 'reasonably want' here.
The thing is, it's 2022, and it does not make any sense to *not* support IPv6, even if one does not connect to any network with IPv6, there's no
harm to just have it there.
Beside 'ipv6', there are other USE flags that I have on mind. 'pam'
being another of them.
On 2 Jan 2022, at 00:03, Scott Ellis <scotte@warped.com> wrote:
Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to have IPv6 support built into things (just another potential "thing" that I have to secure, or errors/warnings I need to suppress since I run an IPv6-less kernel).
If there needs to be a path to culling USE flags, perhaps looking to which flags actually cause packages to pull in additional dependencies (vs solely enable/disable a feature) would be a better place to start?
Note that having USE flags for things, even if forced on/masked (for
the opposite case) is useful for building embedded systems. So, if you
wanted to go this route, a sensible
first step would actually be forcing PAM on. But I don't think PAM is
a candidate for dropping.
While I think it's hard to run a modern desktop system without it,
there are a fair number of people who do still run -pam and I don't
think
breaking it for the sake of it is a good idea. They already know there
be dragons.
Whats your view on it?
I think I broadly agree, although PAM is a mildly controversial
example.
I'd like to discuss specific examples of flags like USE=threads, some-if-not-all instances of USE=ipv6,
And others which people raise if any others come up.
Best,
sam
Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to have
IPv6 support built into things (just another potential "thing" that I have
to secure, or errors/warnings I need to suppress since I run an IPv6-less kernel).
If there needs to be a path to culling USE flags, perhaps looking to which flags actually cause packages to pull in additional dependencies (vs solely enable/disable a feature) would be a better place to start?
Your `ipv6` USE flag hits home - I don't use IPv6, nor do I want to haveMore often than not IPv6 support is transparent and comes down to
IPv6 support built into things (just another potential "thing" that I have
to secure, or errors/warnings I need to suppress since I run an IPv6-less kernel).
As example I'd like to use 'ipv6' USE flag, at the moment of writing
this email there's 351 ebuilds in tree that expose ipv6 as USE flag,
allow it to be disabled.
Beside 'ipv6', there are other USE flags that I have on mind. 'pam'
being another of them.
Hi,
I'd like to get some insight how others see the concept of narrowing the scope of USE flags in Gentoo.
Taking a quote from devmanual:
> USE flags are to control optional dependencies and settings which
the user may reasonably want to select.
I'd like to focus on the 'reasonably want' here. While it is commonly
agreed on that we interface as USE flags only things that make sense to
be togglable, it is not always the case. It is not uncommon to see
packages that puts every possible option as USE flag which hardly
benefit anyone in some cases.
It creates artificial choice of USE flag that makes as much sense as
building and trying to use solar-powered night vision googles. Possible
to be engineered, but makes absolute no sense to exist, yet, there will
be someone who will go with it and then things will not work in desired
way, bugs will be reported, effort will be wasted on investigation and patching things up.
As example I'd like to use 'ipv6' USE flag, at the moment of writing
this email there's 351 ebuilds in tree that expose ipv6 as USE flag,
allow it to be disabled.
The thing is, it's 2022, and it does not make any sense to *not* support IPv6, even if one does not connect to any network with IPv6, there's no
harm to just have it there.
While I am all for choice, I am for choice on things that do make sense.
For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone could argue that since Linux kernel, that is user-configured in Gentoo,
can be built without support for other than UID 0, then Gentoo should
support it. One of the extreme examples of not supporting something that
does not make sense to be supported.
Beside 'ipv6', there are other USE flags that I have on mind. 'pam'
being another of them.
Whats your view on it?
-- Piotr.
On Sat, Jan 1, 2022 at 2:22 PM Piotr Karbowski <slashbeast@gentoo.org> wrote:
Hi,
I'd like to get some insight how others see the concept of narrowing the scope of USE flags in Gentoo.
Taking a quote from devmanual:
> USE flags are to control optional dependencies and settings which
the user may reasonably want to select.
I'd like to focus on the 'reasonably want' here. While it is commonly agreed on that we interface as USE flags only things that make sense to
be togglable, it is not always the case. It is not uncommon to see
packages that puts every possible option as USE flag which hardly
benefit anyone in some cases.
It creates artificial choice of USE flag that makes as much sense as building and trying to use solar-powered night vision googles. Possible
to be engineered, but makes absolute no sense to exist, yet, there will
be someone who will go with it and then things will not work in desired way, bugs will be reported, effort will be wasted on investigation and patching things up.
As example I'd like to use 'ipv6' USE flag, at the moment of writing
this email there's 351 ebuilds in tree that expose ipv6 as USE flag,
allow it to be disabled.
The thing is, it's 2022, and it does not make any sense to *not* support IPv6, even if one does not connect to any network with IPv6, there's no harm to just have it there.
While I am all for choice, I am for choice on things that do make sense. For instance, Linux kernel can be built with CONFIG_MULTIUSER=n, someone could argue that since Linux kernel, that is user-configured in Gentoo,
can be built without support for other than UID 0, then Gentoo should support it. One of the extreme examples of not supporting something that does not make sense to be supported.
Beside 'ipv6', there are other USE flags that I have on mind. 'pam'
being another of them.
Whats your view on it?
I'm trying to understand your principles here. Like on what basis do
you remove or add flags (in general).
I want to remove:
- bash-completion
- acl
- ldap
- policykit
- readline
- sound
(Part of this is just to have a meta discussion so we settle on some
driving principles on why we keep one flag over the other.)
I can easily craft a narrative for getting rid of ipv6, for example,
but I cannot really craft a good narrative for getting rid of pam, or policykit, or ldap as flags. So why do we keep some and remove others?
I'm trying to understand your principles here. Like on what basis do
you remove or add flags (in general).
Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam
shared, does not make sense to be togglable.
Many packages need their ipv6 code disabled if the kernel has no ipv6 support, and enabling ipv6 in the kernel is a pointless security risk
for pretty much anyone in the United States.
https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption
Go troll somewhere else?
On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote:
Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam
shared, does not make sense to be togglable.
Many packages need their ipv6 code disabled if the kernel has no ipv6 support, and enabling ipv6 in the kernel is a pointless security risk
for pretty much anyone in the United States.
On 4 Jan 2022, at 00:29, Michael Orlitzky <mjo@gentoo.org> wrote:
On Mon, 2022-01-03 at 21:29 +0100, Piotr Karbowski wrote:
Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam
shared, does not make sense to be togglable.
Many packages need their ipv6 code disabled if the kernel has no ipv6 support, and enabling ipv6 in the kernel is a pointless security risk
for pretty much anyone in the United States.
On 3 Jan 2022, at 17:16, Alec Warner <antarus@gentoo.org> wrote:
[snip]
I'm trying to understand your principles here. Like on what basis do
you remove or add flags (in general).
I want to remove:
- bash-completion
FWIW, I've managed to remove basically all instances of {bash,zsh}-completion and made upstream PRs (all of one of which have been merged!) for fixing `./configure` behaviour accordingly.
This is in align with our small files policy: https://projects.gentoo.org/qa/policy-guide/installed-files.html#pg0301.
- acl
- ldap
ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
people may want to turn it off and it makes sense to expose
this option for those who do, but we don't need to try support it.
I think some of this kind of comes back to "how do we better
make clear what is/isn't okay (supported)to customise?"
LDAP is a fun one because IIRC we had it enabled by default
for too long and it didn't really break anything when we turned
It off.
Overall, I think we kind of come back to this idea of
trying to just set better IUSE defaults rather than
in profiles, so that it's per-package where possible.
- policykit
This is a reasonable flag to keep given the heavy polkit
dependency of spidermonkey (for now) and it's somewhat
heavy-handed as a concept anyway.
- readline
readline is a tricky one because of its relation with libedit too.
- sound
(Part of this is just to have a meta discussion so we settle on some
driving principles on why we keep one flag over the other.)
I can easily craft a narrative for getting rid of ipv6, for example,
but I cannot really craft a good narrative for getting rid of pam, or policykit, or ldap as flags. So why do we keep some and remove others?
It's very hard to quantify :(
Best,
sam
ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
people may want to turn it off and it makes sense to expose
this option for those who do, but we don't need to try support it.
On Tue, 2022-01-04 at 03:38 +0000, Sam James wrote:
ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
people may want to turn it off and it makes sense to expose
this option for those who do, but we don't need to try support it.
This is another important one. It has security implications, is highly confusing, requires kernel support, and is nonstandard as a USE flag
and as an implementation. Most people should have it off to avoid
surprises, but disabling it in the kernel can make the userland
software complain when explicitly built with ACL support.
I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.
On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky <mjo@gentoo.org> wrote:
On Tue, 2022-01-04 at 03:38 +0000, Sam James wrote:
ACL is kind of similar to what Ionen said for PAM, i.e. sometimes
people may want to turn it off and it makes sense to expose
this option for those who do, but we don't need to try support it.
This is another important one. It has security implications, is highly
confusing, requires kernel support, and is nonstandard as a USE flag
and as an implementation. Most people should have it off to avoid
surprises, but disabling it in the kernel can make the userland
software complain when explicitly built with ACL support.
I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.
Also, you might be able to get away with disabling ACL support on a
server, but desktop users will want ACL support enabled to get
properly functioning udev rules.
On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:And none of which happens unless you intentionally trigger it.
I disagree with the claim that "most people" should disable ACL
support at build time. That just gives you partially functional tools.
The ACL behavior can generally be controlled using runtime options.
I understand why people would disagree in this case, but isn't that a
an argument for having the flag?
There are plenty of great uses for ACLs, but unless you're extremely knowledgeable, they also add a million new ways to compromise your
system. For example, if you untar a file with a default-ACL'd directory
in it and don't notice the little plus sign, you might wind up
unknowingly creating world-writable files. Even if you do notice the
ACL, you have to be an expert in the interaction between umask,
permission bits, the ACL mask, effective permissions, conflicting ACLs,
and all of the tools you're using to understand what will actually
happen or how to properly fix it. It's not something normal people can handle.
And none of which happens unless you intentionally trigger it.
...
Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
very simple, but nothing will break by itself just because you have acl support enabled, you would need to try very hard to run into problems.
On Tue, 2022-01-04 at 19:26 +0100, Piotr Karbowski wrote:
And none of which happens unless you intentionally trigger it.
...
Sure, acl and how chmod manipulate mask on ACL-enabled entities is not
very simple, but nothing will break by itself just because you have acl
support enabled, you would need to try very hard to run into problems.
Even if you're right, and if no other tools invoke tar, and the user is
smart enough not to copy/paste commands from the web, and if no other archivers can extract ACLs when invoked directly or indirectly...
you're still burdening the user to either have faith that this is all
true, or to verify it himself. Repeat the argument for other flags like
ipv6, and you wind up requiring either a lot of faith, or a lot of
diligence, both of which are antithetical to basic principles of
security.
You may not buy the argument, but it's why people disable this stuff,
and the ability to disable it is why a lot of our users user Gentoo to
begin with.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 406 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 108:43:49 |
| Calls: | 8,527 |
| Calls today: | 6 |
| Files: | 13,209 |
| Messages: | 5,920,355 |