public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Eli Schwartz <eschwartz93@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ]
Date: Fri, 9 Feb 2024 16:04:20 -0500	[thread overview]
Message-ID: <4a608d4e-a605-41a7-9d64-3ef4247f834b@gmail.com> (raw)
In-Reply-To: <177a7913d39c590f43a8261b96ebf155b642d6a8.camel@gentoo.org>


[-- Attachment #1.1.1: Type: text/plain, Size: 4703 bytes --]

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

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 18399 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-02-09 21:04 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-09 15:23 [gentoo-dev] special small-files USE flag without effect on dependencies: [ unicode ] Andrey Grozin
2024-02-09 15:43 ` Mike Gilbert
2024-02-09 15:54 ` Ionen Wolkens
2024-02-09 16:07   ` Michael Orlitzky
2024-02-09 16:57     ` Mike Gilbert
2024-02-09 17:17       ` Michael Orlitzky
2024-02-09 18:40         ` Mike Gilbert
2024-02-09 19:09         ` Eli Schwartz
2024-02-09 19:57           ` Michael Orlitzky
2024-02-09 21:04             ` Eli Schwartz [this message]
2024-02-09 21:25               ` Michael Orlitzky
2024-02-09 21:56                 ` Eli Schwartz
2024-02-09 22:56                   ` stefan11111
2024-02-10  0:03                     ` Matt Jolly
2024-02-10 11:48                     ` David Seifert
2024-02-10 17:26                       ` stefan11111
2024-02-11  0:58                         ` Eli Schwartz
2024-02-10 11:22                   ` orbea
2024-02-11  0:58                     ` Eli Schwartz
2024-02-10  0:04               ` Sam James
2024-02-11  0:42                 ` Eli Schwartz
2024-02-11  3:46                   ` Sam James
2024-02-11  3:56                     ` Eli Schwartz
2024-02-12  4:54                     ` Andrey Grozin
2024-02-10  0:00             ` Sam James
2024-02-09 23:52 ` Sam James

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4a608d4e-a605-41a7-9d64-3ef4247f834b@gmail.com \
    --to=eschwartz93@gmail.com \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox