[bug#55903,25/41] gnu: Add go-github-com-protonmail-go-crypto-openpgp.

* gnu/packages/golang.scm (go-github-com-protonmail-go-crypto-openpgp):
  New variable.
---
 gnu/packages/golang.scm | 28 ++++++++++++++++++++++++++++
 1 file changed, 28 insertions(+)

(unmatched-parenthesis via Guix-patches via schreef op za 11-06-2022 om
20:16 [+0100]:
> +     "Package crypto provides cryptography for Go.  This version of the
> +package is a fork that adds a more up-to-date OpenPGP implementation.  It
> +is completely backwards compatible with
> +@url{golang.org/x/crypto,the official package}.")
> +    (license license:bsd-3)))

If it's backward compatible, maybe packaging the fork isn't necessary.
Also, packaging all the forks in the world of everything is unscalable,
so I think we need to at least require that forks look into upstreaming
their changes.  Likewise for other packages in this patch series that
are forks (if any).

Greetings,
Maxime.

On Sat Jun 11, 2022 at 11:27 PM BST, Maxime Devos wrote:
> If it's backward compatible, maybe packaging the fork isn't necessary.

The _API_ is backwards compatible, but packaging it is necessary because
the OpenPGP implementation is different (although you use it the same way).

> Also, packaging all the forks in the world of everything is unscalable,
> so I think we need to at least require that forks look into upstreaming
> their changes.  Likewise for other packages in this patch series that
> are forks (if any).

Go packaging is a bit crazy, seems like this kind of fork overuse is common.
Sadly, it's usually necessary to package the forks. (There'll be a reason
they're using the forks in the first place...)

( schreef op zo 12-06-2022 om 11:46 [+0100]:
> On Sat Jun 11, 2022 at 11:27 PM BST, Maxime Devos wrote:
> > If it's backward compatible, maybe packaging the fork isn't necessary.
> 
> The _API_ is backwards compatible, but packaging it is necessary because
> the OpenPGP implementation is different (although you use it the same way).
>
> [...]
> Go packaging is a bit crazy, seems like this kind of fork overuse is
> common. Sadly, it's usually necessary to package the forks. (There'll
> be a reason they're using the forks in the first place...)

It's not necessary to package the forks if the fork is merged back
upstream, and we can refuse to package impacted packages until things
improve.  Or if upstream is unmaintained, point the
go-golang-org-x-crypto package at the protonmail fork (*).  Go
packaging needs to become less cracy.  We don't have to participate in
spreading the dependency hell.

(*) Looking at
<https://github.com/ProtonMail/go-crypto/issues/21#issuecomment-492792917>,
the reason appears to be a lack of maintaining, but looking at
<https://go.googlesource.com/crypto/>, upstream appears to be active
again, so AFAICT they don't have a reason anymore.

Greetings,
Maxime.

On Sun Jun 12, 2022 at 1:53 PM BST, Maxime Devos wrote:
> we can refuse to package impacted packages until things improve.

I'm not sure boycotting packages is a good idea... If we did that, there'd
be a _lot_ of useful Rust and Go packages that we'd be refusing to package.
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.

> Or if upstream is unmaintained, point the go-golang-org-x-crypto package
> at the protonmail fork.

Seems a little risky just to avoid packaging one fork. It's possible the two
have diverged since the protonmail version was created, too.

> Go packaging needs to become less cracy.  We don't have to participate
> in spreading the dependency hell.

I agree! It's an awful situation created by fundumentally borked dependency
management systems. But I don't see anything we can do about it other than
try to convince people that carelessly adding dependencies is Not A Good
Idea.

( schreef op zo 12-06-2022 om 14:13 [+0100]:
> On Sun Jun 12, 2022 at 1:53 PM BST, Maxime Devos wrote:
> > we can refuse to package impacted packages until things improve.
> 
> I'm not sure boycotting packages is a good idea... If we did that, 

It doesn't have to boycotting.  E.g., the packager could talk with
upstream to look into upstreaming things, helping with preparing the
remaining changes for submitting upstream, submit them, etc.

> there'd be a _lot_ of useful Rust and Go packages that we'd be
> refusing to package.

FWIW, Rust doesn't seem to do forking much, if at all.  And the
multiple-version dependencies thing for a large part disappears with
antioxidant, and in my experience if you send some patches for updating
crates to make some changes for compatibility with newer versions etc.,
the maintainers seem agreeable (and often, albeit not always, the
patches are rather simple), and to a large degree (albeit not always)
upstream does the ‘update to new versions’ things by theirselves.

Also, maybe this would be a lot of Go packages.  But things aren't
going to fix theirselves by ignoring the problems.

Greetings,
Maxime.

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

Okay, when I tried to replace x/crypto with a shim that inherits from
protonmail/crypto, the build of emersion/pgpmail failed. Looks like
protonmail/crypto actually mostly just reexports x/crypto, except for
the parts that it changes. So, sadly, there is no way we can get rid
of this fork.

I also stumbled across this that indicates that the protonmail version
might not actually be as backwards-compatible as it claims to be:
<https://github.com/emersion/hydroxide/pull/102>

I think I've now addressed all your review points. I'll be sending in
a new patchset soon :)