From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms0.migadu.com with LMTPS id aM4pGKnaMWH1ggAAgWs5BA (envelope-from ) for ; Fri, 03 Sep 2021 10:19:53 +0200 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id eEjME6naMWGGSgAAB5/wlQ (envelope-from ) for ; Fri, 03 Sep 2021 08:19:53 +0000 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id DB0FF1BC16 for ; Fri, 3 Sep 2021 10:19:52 +0200 (CEST) Received: from localhost ([::1]:55618 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mM4QR-00050n-Js for larch@yhetil.org; Fri, 03 Sep 2021 04:19:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33644) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM4Ms-0005o9-DM for guix-devel@gnu.org; Fri, 03 Sep 2021 04:16:10 -0400 Received: from mail-4317.protonmail.ch ([185.70.43.17]:27577) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mM4Mo-0006zN-4I for guix-devel@gnu.org; Fri, 03 Sep 2021 04:16:09 -0400 Date: Fri, 03 Sep 2021 08:16:00 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lendvai.name; s=protonmail2; t=1630656962; bh=jSfJkOz7JfRUa+h63tYc37H39lPK5ql7lbQN73WK6e8=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=o35yZnVg4PbgZCVFTMdbM1cYwkR+XVe+kcU0gcCtKaY5CU+TayouZvjPh3tjAlDbO GMnmdRThIDd6owhOo+G5Bx3x+Wd1kHZxXZZpN7KdFWcRn/lzFgVKVyN76I/OdqPV9N c9hBNAY7sf5XiQ1/QazZ5nnXo/jsc6+IXZfFxaDWCs52NSO1JirN/rjBYa898xhYUb sfZVdD7b7rRymLMvRlhaiyhF63plpK77Nyz1CRzbDE58LHMrfJte2PXv2zMa3zo+2x FYvggxCYrONRk0uEEBBiXCTusENzpNsZ59KpOoOTDB3I2L0+ISIeRwsigevoYBz7B/ t1tfsOprpBN/w== To: Maxime Devos From: Attila Lendvai Subject: Re: packaging go-ethereum, and ultimately bee (of ethswarm.org) Message-ID: <0Tgtoa1VWCatLMuCtmTliGT1yG1LDISdAJEQcbQM1jmeNeYg3106tuLHgYxgnR_2f31L9jbREnxViN4jr19NQl1Nwcc2lzc7T64gu4xTKIU=@lendvai.name> In-Reply-To: References: <3a88b1abb853f8217e8dcc05810f1fb3f8468004.camel@telenet.be> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Received-SPF: pass client-ip=185.70.43.17; envelope-from=attila@lendvai.name; helo=mail-4317.protonmail.ch X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: guix-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: Attila Lendvai Cc: "guix-devel@gnu.org" Errors-To: guix-devel-bounces+larch=yhetil.org@gnu.org Sender: "Guix-devel" X-Migadu-Flow: FLOW_IN ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1630657192; h=from:from:sender:sender:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post:dkim-signature; bh=jSfJkOz7JfRUa+h63tYc37H39lPK5ql7lbQN73WK6e8=; b=sTPDyezyR5iGTpUY+26Q3uEFFY3oGmXY0uHTRktQUS4wjBnvDE7c9XovM4yDh1GKo88/Xv Cp/5dF5yMDTExCbWw0dyOaTNW5/gTZ6ihGql8xJRqXPq3MfLxVstkZAl+TF8hNIqTK2R5n bSkRzJ4Z6wp93AB+RMp6Z2SsIjDezC0zAEkplL+Od92JJcRkrqP6TYbbhnkYFcYBQ6U9bW hBmAvbvtnSTTiRsVP0VVnGk+lNe5ZzaJ7wu+MWCMnaZgZJzNpxy55mW0SYf4Ht7j0KpU+T 9HhMnArbSXRvrrZoTfaPC1BBRh6uLVWfaIg90AJJo5Fu9drIg8Vn924dg1eLCg== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1630657192; a=rsa-sha256; cv=none; b=NggDev8oJq0gcpFZdYyfANjTEeMEhkO5+sDaK41P+iW4C+xHQgaYIBOb1HQegCzBXyga8d LNts+0r57APE+wk+4qjSuG8OURCmHwoRvgp858t+97oYvuQoDmRC6/2gm5BxB++xyGvh2u Q2fPykVxMHTCS5w6MVJN7SKFEhBmVOcSZm8reGCJqBkw35JV9t2F8QAzcPKu5766M/bwOF 9PmSVdMeSqkvPe6zdRRQOTmBx7CJA6nkpJgGBsyH+qeiawhmRXdn1kUE83JwKFRnRG/aCN vClrdnAPpG6lxqpjqBdlZpbPCHb4p1RUOTv+PURKtTRkIDW/UEE6LVScSkNwVw== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=lendvai.name header.s=protonmail2 header.b=o35yZnVg; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Spam-Score: -1.12 Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=lendvai.name header.s=protonmail2 header.b=o35yZnVg; dmarc=none; spf=pass (aspmx1.migadu.com: domain of guix-devel-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=guix-devel-bounces@gnu.org X-Migadu-Queue-Id: DB0FF1BC16 X-Spam-Score: -1.12 X-Migadu-Scanner: scn1.migadu.com X-TUID: MlEof0iv1zNv [with some reorderings] > I hope my reply has been valueable. It seems like this discussion > is going to end with =E2=80=98agreeing to disagree=E2=80=99 and I think I= said all > I've got to say about the philosophical part of the matter, so I > don't think I'll sending further replies on the philosophical parts. > But if you have any technical questions, feel free to ask me. ok, noted. your feedback is much appreciated, and i don't mean to argue against the guix philosopy. i'm converted after all! :) so, i'll try to focus on only pointing out perspectives that you may not be aware of, and proposing solutions. > > this mechanism is part of how go builds are reproducible. > > building go-ethereum locally should yield the same binary that they > > have released. > > FWIW, =E2=80=98reproducibility=E2=80=99 in guix means that, if the build = is repeated on another > machine, with the same architecture and guix version, the binaries will b= e > exactly the same. Bit-for-bit reproducibility isn't guaranteed when the b= uilds > are performed on different distro's. thank you for clarifying this! i'll use clearer language when talking about reproducibility. > the loader to be at /lib/lib(64)/ld-linux.[...].so.[...], but that doesn'= t even > exist on Guix, so binaries created on another distro cannot be run on gui= x, FTR, the official binary seems to start up fine on my guix, and begins syncing with some peers: $ ~/.guix-profile/lib/ld-linux-x86-64.so.2 ./geth-linux-amd64-1.10.8-266754= 54/geth --syncmode light it's not statically linked: $ ldd ./geth-linux-amd64-1.10.8-26675454/geth =09linux-vdso.so.1 (0x00007fff26da6000) =09libpthread.so.0 =3D> /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2= .31/lib/libpthread.so.0 (0x00007f86794af000) =09libm.so.6 =3D> /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2.31/li= b/libm.so.6 (0x00007f867936e000) =09librt.so.1 =3D> /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2.31/l= ib/librt.so.1 (0x00007f8679364000) =09libc.so.6 =3D> /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vsfzj7-glibc-2.31/li= b/libc.so.6 (0x00007f86791a7000) =09/lib64/ld-linux-x86-64.so.2 =3D> /gnu/store/ksy2b6fwfmz40gjajvspl87ia4vs= fzj7-glibc-2.31/lib/ld-linux-x86-64.so.2 (0x00007f86794d2000) will this have any pitfalls? is there anything i'm not aware of? if not, then i propose adding a package that downloads the official release, authenticates it by checking its signature, and sets up a wrapper script for it to be able to start it by its proper name. so, maybe we should add two packages? one that fetches the official release binary, and one that builds it from source (and doesn't strictly follow the versions in the project's go.mod file)? i, as a user, would be more relaxed running the authenticated official binary release. maybe this is misguided, and in that case i'm happy to be corrected. > > building go-ethereum locally should yield the same binary that they > > have released. > > ... why should it? so that, ideally, we are able to use the trusted guix intrastructure to rebuild the same binary locally that the project has released... and with that double-check also the release process of the upstream. > > > Another problem is: if a go package has many (transitive) dependencie= s, how do > > > we check that it doesn't contain any malware or non-free components? = That needs > > > > go-ethereum is a software that handles ethereum wallets with several > > zeroes. they are probably equally worried about this if not more. > > I'm sure the go-ethereum peope wouldn't mind if we double-check that no m= alware > slipt through their review process. [...] > > for projects like go-ethereum, it's not an option for the packager to > > make decisions about the version of any of its dependencies. > > Why isn't this an option? Choosing different versions from upstream is al= ready > done in guix, see e.g. https://issues.guix.gnu.org/50217 (ok that's not m= erged > yet, not the best example --- note, editing the version requirement was > on my advice, see https://logs.guix.gnu.org/guix/2021-08-26.log). extra auditing on top of the official release is certainly welcome by each player. but, realisticly, i doubt that the hundreds of guix go packages will get comparable amount of security-auditing-attention any time soon. let alone -- and this is of key importance here -- auditing any possible cross-interactions of altered versions of the dependencies! who else is qualified to do that better than the developers themselves? for a program like the ethereum client, any such semantic surprises may be disasterous. (losing money in various ways. e.g. their client forking off of the consensus of the ethereum network, and if e.g. they are paricipating in staking, then they will suffer penalties for not adhering to the rules of the network, etc.) this is why i would prefer to have a solution that somehow reproduces, compares, and runs the same binary as the officially released one. in the follwig days i'll play with reproducing the geth release binary on my guix, and also planning to mock up a binary downloader package, and see how it goes. i'll report back with anything worth mentioning. > I see a third viable option (3): treat the "go.sum" as a mere > =E2=80=98friendly suggestion=E2=80=99, and just use the latest version wh= en feasible. > Again, I don't see much difference with, say, haskell, python, ruby, > guile, java ... packages. my point here is not that all go projects should be packaged like this (i.e. with exacly pinned dependencies), but that applications like geth should be, regardless of the language they are written in. in case of a random image viewer written in go, i'm all in for a relaxed handling of dependencies. > Have there been any problems in practice with just using the latest > version (updating the version currently in guix where applicable)? not that i'm aware of, but the first such identified issue could turn out to be very expensive. - attila