guix-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#55903] [PATCH 25/41] gnu: Add go-github-com-protonmail-go-crypto-op


From: Maxime Devos
Subject: [bug#55903] [PATCH 25/41] gnu: Add go-github-com-protonmail-go-crypto-openpgp.
Date: Sun, 12 Jun 2022 15:57:38 +0200
User-agent: Evolution 3.38.3-1

( schreef op zo 12-06-2022 om 14:13 [+0100]:
> Seems a little risky just to avoid packaging one fork

It's not about _one_ fork, it's about forks in general.
And wasn't it backwards compatible?  And no need the slightly risky
‘point the go-golang-org-x-crypto package at protonmail’ if it is
upstreamed instead.

> Anyway, I think it'd probably just drive people even further away
> from distribution package management towards the "modern" (read:
> insecure, bloated, and inherently flawed) stuff like Docker and
> Flatpak.

At some point, if people shoot theirselves in the foot by being misled
by other projects, that's not something Guix can help with avoiding I
think.  (Unless someone wants to start an awareness campaign?)

Anyway, I don't follow -- your proposal is to include all the forks
where used by upstream, which leads to insecurity because:

  * more packages -> more complexity -> more difficult to do changes
  * more packages -> more packages that can be out-of-date
  * more forks -> more forks that might be unmaintained and hence be at
    risk of being known-insecure by attackers without an update
    available
  * more packages -> more packages that need to be updated -> less time
    for structural improvement on security
  * more packages -> more opportunity for malware to enter.

and also:

  * more packages that +- do the same thing -> bloat

So from here, the proposal implies making packaging in Guix worse in
some aspects, such that people don't use other system's that are bad in
the same aspects ...  I don't think it's a good idea to start a ‘race
to the bottom’ [0].

[0] https://en.wikipedia.org/wiki/Race_to_the_bottom

Greetings,
Maxime.

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]