From: Vagrant Cascadian <vagrant@reproducible-builds.org>
To: Maxime Devos <maximedevos@telenet.be>,
jbranso@dismail.de, guix-devel@gnu.org
Subject: Re: U.S. Midwest based build farm
Date: Sat, 11 Jun 2022 16:05:38 -0700 [thread overview]
Message-ID: <874k0qyf5p.fsf@contorta> (raw)
In-Reply-To: <1c9065963fe7fed97613bc641e40d5f082c60e9b.camel@telenet.be>
[-- Attachment #1: Type: text/plain, Size: 2710 bytes --]
On 2022-06-11, Maxime Devos wrote:
> jbranso@dismail.de schreef op za 11-06-2022 om 16:06 [+0000]:
>> What's good and/or bad about this idea?
>
> A positive point: extra resources, could be useful for reproducibility
> testing, ...?
>
> A negative point: extra points through with malware can be introduced
> (->compromises). Can be solved by reproducible builds and variation of
> "guix challenge". Unfortunately, "guix challenge" is inherently racy.
> "guix substitute" currently only checks that the narinfo has a _single_
> authorised signature, maybe it can be adjusted to allow the user to
> ask: ‘only consider a substitute to be authorised if the same hash is
> signed by N different authorised keys’?
Even without "signed by N" reproducible builds and guix substitute
servers have some very interesting qualities!
It's been a while since I've tested, but I seem to recall setting up a
situation where I had a untrusted substitute server locally (e.g. I
didn't add that server's keys to guix's trusted keys), and also
configured my guix machine to use the default guix substitute servers
(which were in the guix acl for authorized keys).
Roughly approximated as:
guix COMMAND --substitute-urls='https://untrusted.example.com https://ci.guix.gnu.org https://bordeaux.guix.gnu.org'
For packages that build reproducibly, you could actually download the
signatures (which are fairly small) from the "trusted" substitute
servers, but download the actual packages (which can be quite large)
from the "untrusted" substitute server...
I've actually been wondering if one couldn't make this behavior more
explicit, e.g. have substitute servers that *only* served signatures,
and substitute servers that *only* served (unsigned?) builds. I guess
you can more-or-less create this effect by never publishing the key that
packages are signed with for the untrusted/untrustable substitute
server?
Anything that you can download from the "unstrusted" server is
demonstratably reproducible, because a "trusted" server also built it.
presuming, of course, both servers are actually performing the builds,
but worst case you still get the bit-for-bit identical packages as the
"trusted" substitutes.
It's an awesome way to be able to distribute the downloads for that 80%
and growing number of packages that are reproducible away from the
default substitute servers, without actually having to even place much
trust an arbitrary third party, other than metadata about what you've
downloaded...
I remember this being one of my favorite features of guix that I learned
about early on, but haven't really done much with it!
live well,
vagrant
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]
next prev parent reply other threads:[~2022-06-11 23:06 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-11 16:06 U.S. Midwest based build farm jbranso
2022-06-11 20:00 ` Maxime Devos
2022-06-11 23:05 ` Vagrant Cascadian [this message]
2022-06-11 20:13 ` jbranso
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874k0qyf5p.fsf@contorta \
--to=vagrant@reproducible-builds.org \
--cc=guix-devel@gnu.org \
--cc=jbranso@dismail.de \
--cc=maximedevos@telenet.be \
/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.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).