Message ID | 20220611191653.15471-25-paren@disroot.org |
---|---|
State | New |
Headers |
Return-Path: <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org> X-Original-To: patchwork@mira.cbaines.net Delivered-To: patchwork@mira.cbaines.net Received: by mira.cbaines.net (Postfix, from userid 113) id 1E5C027BBEB; Sat, 11 Jun 2022 20:19:34 +0100 (BST) X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on mira.cbaines.net X-Spam-Level: X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_INVALID, DKIM_SIGNED,MAILING_LIST_MULTI,SPF_HELO_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.6 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) by mira.cbaines.net (Postfix) with ESMTPS id 622C527BBEA for <patchwork@mira.cbaines.net>; Sat, 11 Jun 2022 20:19:33 +0100 (BST) Received: from localhost ([::1]:34140 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org>) id 1o06dw-0004fz-Gt for patchwork@mira.cbaines.net; Sat, 11 Jun 2022 15:19:32 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57044) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1o06ce-0002EZ-IK for guix-patches@gnu.org; Sat, 11 Jun 2022 15:18:12 -0400 Received: from debbugs.gnu.org ([209.51.188.43]:60140) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1o06ce-0007fm-A8 for guix-patches@gnu.org; Sat, 11 Jun 2022 15:18:12 -0400 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from <Debian-debbugs@debbugs.gnu.org>) id 1o06ce-00050b-63 for guix-patches@gnu.org; Sat, 11 Jun 2022 15:18:12 -0400 X-Loop: help-debbugs@gnu.org Subject: [bug#55903] [PATCH 25/41] gnu: Add go-github-com-protonmail-go-crypto-openpgp. Resent-From: "(unmatched-parenthesis" <paren@disroot.org> Original-Sender: "Debbugs-submit" <debbugs-submit-bounces@debbugs.gnu.org> Resent-CC: guix-patches@gnu.org Resent-Date: Sat, 11 Jun 2022 19:18:12 +0000 Resent-Message-ID: <handler.55903.B55903.165497507018950@debbugs.gnu.org> Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55903 X-GNU-PR-Package: guix-patches X-GNU-PR-Keywords: patch To: 55903@debbugs.gnu.org Cc: "\(unmatched-parenthesis" <paren@disroot.org> Received: via spool by 55903-submit@debbugs.gnu.org id=B55903.165497507018950 (code B ref 55903); Sat, 11 Jun 2022 19:18:12 +0000 Received: (at 55903) by debbugs.gnu.org; 11 Jun 2022 19:17:50 +0000 Received: from localhost ([127.0.0.1]:53983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <debbugs-submit-bounces@debbugs.gnu.org>) id 1o06cH-0004vP-Mn for submit@debbugs.gnu.org; Sat, 11 Jun 2022 15:17:50 -0400 Received: from knopi.disroot.org ([178.21.23.139]:52156) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from <paren@disroot.org>) id 1o06c3-0004rs-9f for 55903@debbugs.gnu.org; Sat, 11 Jun 2022 15:17:36 -0400 Received: from localhost (localhost [127.0.0.1]) by disroot.org (Postfix) with ESMTP id 255CB43CAB; Sat, 11 Jun 2022 21:17:35 +0200 (CEST) X-Virus-Scanned: SPAM Filter at disroot.org Received: from knopi.disroot.org ([127.0.0.1]) by localhost (disroot.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nowa02kLb-Xs; Sat, 11 Jun 2022 21:17:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=disroot.org; s=mail; t=1654975042; bh=SlBkup/pcTl+UvaCaFhzHXk4puIdgIjc9YRKJlvOSLM=; h=From:To:Cc:Subject:Date:In-Reply-To:References; b=BDalRq1e6EhHW0yI9qolIxw6nVI1HA0By+SYRYUa6ENs0FGns9eks8BFtoLosvS0Q WRYLEdvwjIQHpYMXlOrce2iamwb6p3brxUzl6+jAJnK5CeiSd+EAqZD0uZMpcp4lsP wNI5wHmYqwC+ZGf/1KZCTkn3pNrB+Kz4uxIlep+SUp8L1figfmC2F+kHSxPMd5SBSq YKOpCfGJrQAnSsxE3CPB9R0cvcWBmJmU1nyNXeb91s6QIIDAXF7eSS9LkCwoW/Plcr vRx9vIS5f9hYSXj9XZ/cVqE7acwyILNrEW91cgPfcZtVfVLwbzJwIiiLYYN2N+f5Hj XsptChumFGMRw== Date: Sat, 11 Jun 2022 20:16:37 +0100 Message-Id: <20220611191653.15471-25-paren@disroot.org> In-Reply-To: <20220611191653.15471-1-paren@disroot.org> References: <20220611191653.15471-1-paren@disroot.org> Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: guix-patches@gnu.org List-Id: <guix-patches.gnu.org> List-Unsubscribe: <https://lists.gnu.org/mailman/options/guix-patches>, <mailto:guix-patches-request@gnu.org?subject=unsubscribe> List-Archive: <https://lists.gnu.org/archive/html/guix-patches> List-Post: <mailto:guix-patches@gnu.org> List-Help: <mailto:guix-patches-request@gnu.org?subject=help> List-Subscribe: <https://lists.gnu.org/mailman/listinfo/guix-patches>, <mailto:guix-patches-request@gnu.org?subject=subscribe> Errors-To: guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org Sender: "Guix-patches" <guix-patches-bounces+patchwork=mira.cbaines.net@gnu.org> Reply-to: "\(unmatched-parenthesis" <paren@disroot.org> X-ACL-Warn: , "\(unmatched-parenthesis via Guix-patches" <guix-patches@gnu.org> From: "\(unmatched-parenthesis via Guix-patches" via <guix-patches@gnu.org> X-getmail-retrieved-from-mailbox: Patches |
Series |
[bug#55903,01/41] gnu: Add go-github-com-zenhack-go-notmuch.
|
|
Commit Message
\(
June 11, 2022, 7:16 p.m. UTC
* gnu/packages/golang.scm (go-github-com-protonmail-go-crypto-openpgp): New variable. --- gnu/packages/golang.scm | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+)
Comments
(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 :)
diff --git a/gnu/packages/golang.scm b/gnu/packages/golang.scm index b66ded6f61..06d635b03b 100644 --- a/gnu/packages/golang.scm +++ b/gnu/packages/golang.scm @@ -10435,3 +10435,31 @@ (define-public go-github-com-emersion-go-imap-sortthread (synopsis "SORT and THREAD for go-imap") (description "Package sortthread implements SORT and THREAD for go-imap.") (license license:expat))) + +(define-public go-github-com-protonmail-go-crypto-openpgp + (package + (name "go-github-com-protonmail-go-crypto-openpgp") + (version "0.0.0-20220517143526-88bb52951d5b") + (source (origin + (method git-fetch) + (uri (git-reference + (url "https://github.com/ProtonMail/go-crypto") + (commit (go-version->git-ref version)))) + (file-name (git-file-name name version)) + (sha256 + (base32 + "15dsjxsgr6sbfi651kav3vcfpkkzfb383rahasff4fvb6hwfjr1l")))) + (build-system go-build-system) + (arguments + (list #:import-path "github.com/ProtonMail/go-crypto/openpgp" + #:unpack-path "github.com/ProtonMail/go-crypto")) + (propagated-inputs (list go-golang-org-x-crypto)) + (home-page "https://github.com/ProtonMail/go-crypto") + (synopsis "Fork of golang.org/x/crypto with up-to-date OpenPGP +implementation") + (description + "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)))