all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Reproducible Builds Summit 2022
@ 2022-11-03 13:44 Efraim Flashner
  2022-11-03 15:25 ` Ludovic Courtès
                   ` (2 more replies)
  0 siblings, 3 replies; 6+ messages in thread
From: Efraim Flashner @ 2022-11-03 13:44 UTC (permalink / raw)
  To: guix-devel

[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]

Chris and I are here at the reproducible builds summit in Venice, we're
winding down now but it's been a great time meeting everyone and
planning out upcoming tasks.

The good news is Guix is Great! We have our tightly controlled
dependency chain which makes it really easy to know exactly which inputs
were present during a build and how to rebuild a package to check for
reproducibility. We have Guix challenge to easily challenge the build
farms to see if locally available packages are reproducible against the
ones built on the build farms.

I'm going to link to Vagrant's email^1 from back in June where they
talked about some of the unreproducibility issues in Guix. We know the
issues are there, so it would be good for us to go ahead and fix them.
They might not all be low hanging fruit, but we do want to make sure
that our builds continue to be reproducible.

Moving forward, it would be nice to test for reproducibility in
qa.guix.gnu.org. It should be possible to build packages more than once
and to compare the results of the two to check for reproducibility.
qa.guix.gnu.org already shows which packages in patches build for each
architecture, being able to check for reproducibility also would be a
good next step.  We should also continue working on implementing a
change in the ACL to allow requiring a K of N agreement between
different substitute servers that a build is correct^2. If someone is
downloading substitutes I'm sure they would be happier to know that the
two build farms (or more if you have access to more build farms!) agree
to the hash of the packages.

Other ideas moving forward is the ability to sign a narinfo with more
than one key. Then in theory these multisigned narinfo files could be
distributed and one could trust it without putting undue load on the
substitute servers. This would also be helpful if there are network
problems but we want to have that not affect the distribution of nars.

^1 https://lists.gnu.org/archive/html/guix-devel/2022-06/msg00191.html
^2 https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00179.html

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2022-11-05 18:04 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2022-11-03 13:44 Reproducible Builds Summit 2022 Efraim Flashner
2022-11-03 15:25 ` Ludovic Courtès
2022-11-05 10:18 ` Reproducible Builds Summit 2022, nar support in diffoscope Christopher Baines
2022-11-05 18:04   ` Ludovic Courtès
2022-11-05 12:30 ` Reproducible Builds Summit 2022 zimoun
2022-11-05 13:25   ` Christopher Baines

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.