On 2/9/24 2:57 PM, Michael Orlitzky wrote:
> One example I know off the top of my head is dev-lang/php where
> USE=ipv6 isn't entirely about ipv6 connectivity (although it does do
> that). It also augments some of the user-facing PHP language functions
> with ipv6 support. Having them enabled is not a big deal, and PHP is a
> programming language so you may say that it's atypical, but... for a
> package that gets a new CVE every week and sits on the public web, I'd
> just rather have it off?


Counterpoint: some PHP program out there is probably vulnerable because
it tried to validate an ipv6 address and could not distinguish between
"it's okay" and "idk if it's okay, the function you called does not
exist" (because php is really that terrible of a language).

I'm confused why you think compiling or not compiling in support for
part of a programming language is supposed to make CVEs *less* likely to
happen, rather than more likely?

In the most optimistic scenario, it's a denial of service CVE because
part of the programming language got deleted, instead of a remote code
execution vulnerability because the application didn't correctly handle
the consequences of silently returning NULL.


> Unicode support is similar in my mind. Adding "unicode support" to a
> package might be easy (at the cost of some extra memory), but dealing
> with the consequences of unicode is harder. Maybe I don't want to worry
> about homoglyphs and bidirectional text when I'm validating a hostname?
> Life is just simpler without it, if you know you don't need it.


... and this is a property of the way you build the programming language
rather than your choice of APIs when you compile your own software
*using* sbcl?


> Things
> also tend to be more space and memory efficient with features compiled
> out; not to mention that the compile times themselves are improved.
> You're still pulling in "extra dependencies," in a sense, even if
> they're in the same tarball.


That sounds trivial to demonstrate. Can you describe the timings on how
long a src_compile takes with and without this USE flag? What is the
resulting size of the package?

I will note that using -march=native also has an effect on compile time,
and space and memory efficiency. But it is a feature of your CFLAGS, not
USE.

This invites another thought, for me. Gentoo doesn't necessarily need to
support every possible option, since package.env can set EXTRA_ECONF,
MYMESONARGS, MYCMAKEARGS.

eclass-based overrides, too, are part of "Gentoo is about choice". I use
this myself for things that aren't controllable as USE flags.


> I really don't want to fall into a trap where I make up reasons why
> other people might want to do things and everyone says my reasons are
> stupid. Everyone is going to have different reasons, and we have a lot
> of users who are our users because they're edge cases.
> 
> It's not unfathomably stupid to build a package without ipv6 or unicode
> support (whatever that means), and there are no small files to worry
> about, so I don't think they deserve the special negative treatment.


Maintainability matters too. So does user experience in the other
direction: too many USE flags will lead users to confusion if they don't
understand what all those flags do, and accidentally choose the wrong
answer.

That's not necessarily a reason to remove choice, so much as it is a
reason to... carefully document what that choice actually gets you.

$ equery -N uses sbcl | grep unicode
 + + unicode          : Add support for Unicode


This is... vague. Good to know that it is enabled by default, but...
what? What does it do? There is no description in metadata.xml, either.

I think it is fair and reasonable for people to ask people's reasons are
for doing something when it is not actually obvious what the point is.
And when a USE flag selects or deselects dependencies, it is very easy
to know, what exactly "the point" is.

Often, USE flags have an obvious point even without selecting or
deselecting dependencies -- usually because their maintainers took care
in describing it in metadata.xml.


If people disagree about the specific choice itself, that's one thing
(and Gentoo values respecting all sides, though not unconditionally so
-- see libressl and eudev for examples where choice was booted out of
::gentoo, and people were told they'd have to homebrew their own
overlays if they wanted that choice).

It's another thing entirely when people cannot see what the choice
actually is, and start suspecting that there is no choice, "the choice
is a lie".


-- 
Eli Schwartz