Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

On 04/01/2022 20.18, Michael Orlitzky wrote:

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.


I was challenging here your opinion that most people should disable acl 
support.


And what I showed is that, by keeping it enabled, does not bring on you 
potential problems beside possible security issues in the code that you 
keep around and not want to have around.


Sure, there are valid reasons to strip things from kernel, I've seen 
some tor nodes running kernel without input devices all out of 
initramfs, such usecase do make sense.


However I am strongly against opinion that most people should not enable 
acl, unless you have 16 MB NOR flash storage and every kB of kernel 
image counts, but then it's unlikely that you'd use gentoo there in the 
first place, since bundling headers and whole toolchain would east a lot 
of storage.


I know there are people who love to disable things, there are even 
people who says that pam is bloatware and strip it, or people who, 
security reason as they claim, refuse to use logind provider (elogind or 
systemd) and instead choose to run Xorg as root.


-- Piotr.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

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.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 04/01/2022 18.35, Michael Orlitzky wrote:

On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:


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.

1. To have ACL break things on new (extracted) files you'd first need to 
have default ACL set on parent directory where you extract to -- 
otherwise they won't be carried and no problem


2. unless you add --acl to both create and extract, no acl will be added 
to tarball and/or extracted onto system


Running 'tar --acl ...' or 'setfacl -d ...' does not happen by accident 
and argument that you should disable acl to not run into issues with 
above does not make much sense.


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.


-- Piotr.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

On Tue, 2022-01-04 at 12:03 -0500, Mike Gilbert wrote:
> 
> 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.

If you don't need them for anything, it's just nice not to have to
worry about those issues.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 04/01/2022 18.03, Mike Gilbert wrote:

On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky  wrote:


On Tue, 2022-01-04 at 03:38 +, 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.



I second this.

As far as Desktop is concerned acl is basic feature that should be there 
along with extended attributes, for example, I am pretty sure 
systemd-login will use acl to grant access to inputs in /dev for the 
logged user.


acl is as much needed as support for multiple users (CONFIG_MULTIUSER), 
and it also needs support on kernel level, because without this symbol 
hardly anything will work for you. What I mean here is that argument 
'needs support in kernel' is not a problem, because everything does need 
a support in kernel. Try to boot without CONFIG_FUTEX as example, it can 
be disabled so you could say that it needs support in kernel in a way to 
constitute that this is something bad and thus should be avoided.


-- Piotr.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Mike Gilbert]

On Tue, Jan 4, 2022 at 12:31 AM Michael Orlitzky  wrote:
>
> On Tue, 2022-01-04 at 03:38 +, 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.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Alec Warner]

On Mon, Jan 3, 2022 at 7:39 PM Sam James  wrote:
>
>
>
> On 3 Jan 2022, at 17:16, Alec Warner  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 feel like 'acl' or 'pam' or 'policykit' are not really USE flags in
the general sense. They are more like profile settings. You don't want
to toggle these flags, you want to switch profiles. I think
conceptually profile migrations are larger changes that require a
rebuild of a bunch of stuff, and typically have downtime (e.g. where
your system isn't expected to work the entire time.)

There are practical problems with profile proliferation, but I think
it is closer to what these flags represent, if that makes sense.

-A


>
> 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
>

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

On Tue, 2022-01-04 at 03:38 +, 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.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Sam James]

> On 3 Jan 2022, at 17:16, Alec Warner  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



signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Sam James]

> On 4 Jan 2022, at 00:29, Michael Orlitzky  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.
> 

Obviously for such cases, the flag should be kept. But that's not
the case for plenty of packages.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

On Mon, 2022-01-03 at 16:51 -0800, Alec Warner wrote:
> > 
> > 
> > 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?
> 

Anyway, leave the USE flag please.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Alec Warner]

On Mon, Jan 3, 2022 at 4:29 PM Michael Orlitzky  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.

https://www.google.com/intl/en/ipv6/statistics.html#tab=per-country-ipv6-adoption

Go troll somewhere else?

-A

>
>
>

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Michael Orlitzky]

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.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 03/01/2022 18.16, Alec Warner wrote:

I'm trying to understand your principles here. Like on what basis do
you remove or add flags (in general).


My principals is to end-user experience over exposing as much as 
possible as USE flags.


A real life example

media-sound/deadbeef

	The .mp3 support can either use libmad or libmpg123. The first one is 
dead upstream, while code work currently with it, because it is dead, I 
rather avoid some setups where users setup +mad instead of +mpg123 that 
are mutually exclusive and run into some issues, like crashes, that 
would waste a lot of time on debugging it, so I made it that mp3 depends 
on libmpg123 without option for libmad. Some overlay-provided ebuilds 
for it do have option for libmad, I decided to not include it.


If you'd decide to give user a choice, you would make it as USE flag, 
but from end-user perspective it does not provide any benefit, and from 
maintainer perspective it's better to reduce error surface.


Perhaps the 'pam' example was extreme, but ipv6, or threads as Sam 
shared, does not make sense to be togglable.


-- Piotr

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Mike Gilbert]

On Mon, Jan 3, 2022 at 12:16 PM Alec Warner  wrote:
>
> On Sat, Jan 1, 2022 at 2:22 PM Piotr Karbowski  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?

The devmanual has a section on this topic:

https://devmanual.gentoo.org/general-concepts/use-flags/index.html#when-not-to-use-use-flags

Personally, I use the following principles:

Is there an optional build time dependency, and is the package still
useful without said dependency? If so, a USE flag is warranted.

Is there some optional feature/behavior that can only be toggled at
build time? If so, a USE flag is probably warranted.

Is there some optional feature/behavior that can be toggled at run
time (via config)? Does disabling it at build time have a minimal
effect on the installed size? If so, I will NOT add a USE flag.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Alec Warner]

On Sat, Jan 1, 2022 at 2:22 PM Piotr Karbowski  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?

-A

>
> -- Piotr.
>

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Ionen Wolkens]

On Sat, Jan 01, 2022 at 11:21:40PM +0100, Piotr Karbowski wrote:
> 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.

This is a flag I've usually been removing when I touch a package
already, not that I'd want to spearhead removing it from /all/
packages at once but well.

In most cases it's:
- an upstream default
- has no extra dependencies
- doesn't increase file size in any noticeable way
- ipv6 is expected to work
- USE=-ipv6 tend to have less-tested code paths that I've seen cause
  issues even for ipv4
- not really anything to gain by disabling in a specific package even
  if you don't use ipv6, there's plenty of ways to disable ipv6
- majority of packages don't even have a switch to disable either way,
  this is mostly historical switches from early days of support

I'd keep it if say the package needed libsuperipv6 or something as I'm
not particularly an advocate that it /must/ be supported, and in this
case libsuperipv6 may be less wanted or even not supported on some
arches (maybe was written in rust!)

> Beside 'ipv6', there are other USE flags that I have on mind. 'pam' 
> being another of them.

That's one I think needs to be kept even if I don't like the idea of
normal desktop system arbitrarily disabling it where about everything
expects it to be used.

Disabling can make sense on prefix, embedded systems and similar --
and it also need extra dependencies and cause more relevant changes
in behavior that users should be free to want or not.

Not that should be responsible for upstreams supporting disabling it,
so when they don't just depend on it being enabled (what we do now).

-- 
ionen


signature.asc
Description: PGP signature

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Roy Bamford]

On 2022.01.02 07:33, Sam James wrote:
> 
[snip]

> 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
> 

I'll stir the USE=-pam pot. 
A static busybox is a very good thing but that can only be achieved with 
USE=-pam.

Sometimes it's the only way to pick up the pieces.

In general, where USE=-foo makes the code size smaller I would be 
against dropping it. Think non Intel/AMD memory constrained systems.

Gentoo is popular outside the desktop, so keep those users in mind too.

-- 
Regards,

Roy Bamford
(Neddyseagoon) a member of
elections
gentoo-ops
forum-mods
arm64

pgpCLMlWhJelZ.pgp
Description: PGP signature

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

Hi,

On 02/01/2022 01.03, Scott Ellis 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?


And here I am having a deja vu, an associate of mine who happens to use 
Gentoo also intentionally runs without IPv6. When we were traveling out 
of country he was unable to use WIFI hotspot that I was connected to, 
turns out, it was IPv6-only hotspot with NAT64 gateway. I had internet 
access, he had rant about why IPv6-only networks are abomination  and 
that he never seen a network like it.


He won nothing, and neither do you win anything running without IPv6 
support.


-- Piotr.

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Sam James]

> On 2 Jan 2022, at 00:03, Scott Ellis  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?
> 

Yep, that's a good idea, but please do see my other comments on IPv6. USE=ipv6 
actually has some problematic properties
aside from people wanting (or not wanting) IPv6.

One reason being that it's often not even a supported configuration upstream, 
but there's others I mentioned too.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Sam James]

> On 2 Jan 2022, at 04:28, Blake Bartenbach  wrote:
> 
> On Sat Jan 1, 2022 at 4:21 PM CST, Piotr Karbowski wrote:
>> 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.
>> 
> 
> This kind of logic goes down a slippery slope very quickly though.
> "There's no harm to just have it there" kind of defeats the purpose of a
> configurable operating system.

Yeah, agreed on that part. We can't really deny that Gentoo is
the home of tweakers and ricers, even if we have other types of user too.

The main aim should be to avoid complexity in ebuilds and invalid
bug reports. Masking/forcing on flags as appropriate avoids
most of these issues.

But on IPv6, please see my other post. If we have to use an autoconf
cache variable to force IPv6 off, that suggests it's probably not even
a supported configuration upstream.

> 
>> Beside 'ipv6', there are other USE flags that I have on mind. 'pam'
>> being another of them.
>> 
> 
> Well, I'm not sure about the pam one. The only USE flag that
> consistently baffles me is 'X'. It really does not seem to have a well
> defined definition, and it seems to do different things with different
> packages. For the longest time, I had that flag globally disabled, but
> used X and almost every package worked totally fine.
> 

Somewhat related: we've started moving to USE=gui to help
the situation a bit. See 
https://projects.gentoo.org/qa/policy-guide/use-flags.html#pg0802 
.

Best,
sam


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Sam James]

> On 1 Jan 2022, at 22:21, Piotr Karbowski  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.

There's two flags which come to mind:

- USE=ipv6:

IPv6 is a good example of a flag we may want to kill. The reason being that 
usually the flag
is ineffective -- we don't actually expose it consistently across all packages 
that may
support it in the build system, and even when there's technically a method for 
such
In the build system, it's fragile (autoconf cache variables, usually).

A good example of this recently was app-editors/vim. I looked into exactly
what "disabling" IPv6 for an editor meant. _All_ it did was force use of
older POSIX socket functions which lack support for IPv6. These newer
functions which were disabled *were not* IPv6-only.

If you don't want IPv6, you should really disable it in the kernel and
ensure you don't have any IPv6 interfaces setup.

I genuinely don't think USE=ipv6 adds any value most of the time
for the aforementioned reasons. If it really does enable/disable
a huge chunk of code, maybe it makes sense to keep it for such
a package, but in general, every time I've checked, it's
been nebulous.

TL;DR: The flag doesn't exist in plenty of packages
and usually it's rather fragile. I don't think we should keep
it where it toggles something simple like Vim (I removed it
for that reason).

- USE=threads:

Rather dangerous flag at this point, I reckon. We should really
default to on/off as appropriate per-upstream. Usually upstream
roll with one supported configuration (it's either recommended
you have it on or off) and that's it.

If someone puts "USE=threads" in make.conf expecting a speedup
or something good to come out of it, they'd be mistaken.

I'd prefer to only keep it for where there's some API change
or meaningful reason to want it. Otherwise we should just default to
upstream behaviour.


> 
> 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.

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


signature.asc
Description: Message signed with OpenPGP

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Blake Bartenbach]

On Sat Jan 1, 2022 at 4:21 PM CST, Piotr Karbowski wrote:
> I'd like to focus on the 'reasonably want' here.
>

I find that words like "reasonable" are generally useless. The issue
is, it's completely subjective. Do you think the average
person would think that using Gentoo is reasonable for their home
computing? Is it resonable for grandma? I think it's reasonable for me.

> 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.
>

This kind of logic goes down a slippery slope very quickly though.
"There's no harm to just have it there" kind of defeats the purpose of a
configurable operating system.

> Beside 'ipv6', there are other USE flags that I have on mind. 'pam'
> being another of them.
>

Well, I'm not sure about the pam one. The only USE flag that
consistently baffles me is 'X'. It really does not seem to have a well
defined definition, and it seems to do different things with different
packages. For the longest time, I had that flag globally disabled, but
used X and almost every package worked totally fine.

-- Blake

Re: [gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Scott Ellis]

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?

   ScottE

[gentoo-dev] Rationalizing USE flags by narrowing the scope of them.

[Piotr Karbowski]

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.