Reproducible Builds Summit 2022

Reproducible Builds Summit 2022

[Efraim Flashner]

[-- 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 --]

Re: Reproducible Builds Summit 2022

[Ludovic Courtès]

Hello!

Efraim Flashner <efraim@flashner.co.il> skribis:

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

Thanks for the report!  I have fond memories of previous editions of the
summit, I hope this was as pleasant as in previous years.

There are well-identified things we can do to move forward, let’s hope
we get there by the next summit.  :-)

Ludo’.

Re: Reproducible Builds Summit 2022, nar support in diffoscope

[Christopher Baines]

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


Efraim Flashner <efraim@flashner.co.il> writes:

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

One thing I forgot to tell Efraim about is that I got around to looking
at nar support in diffoscope. I know this isn't essential as you can
just unpack the nars, then compare (as I think guix challenge does), but
I've been thinking this could make it easier to compare nars.

Anyway, as part of this I proposed adding lzip support, since nars can
be lzipped, that turned out to be quite easy:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/106

I'm finding nar support a bit harder though, I've raised a merge request
anyway to see if I can get any feedback:

  https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/107

Chris

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

Re: Reproducible Builds Summit 2022

[zimoun]

Hi,

Really cool!  Thank you for the heads-up.

On Thu, 03 Nov 2022 at 15:44, Efraim Flashner <efraim@flashner.co.il> wrote:

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

I am not a specialist about consensus algorithm so maybe I am totally
out of topic.  This K-of-N agreement looks like a Proof of Stake [1].

Well, the problem looks like «Byzantine generals problem» [2] and I do
not know what is the state of the art.  Somehow Paxos [3] algorithm and
variants are often implemented to keep consistent a distributed database
(which is another way to see “different substitute servers”).

Maybe, it could be worth to compare the various approaches… well, if it
has not already been done. :-)

1: <https://en.wikipedia.org/wiki/Proof_of_stake>
2: <https://en.wikipedia.org/wiki/Byzantine_fault>
3: <https://en.wikipedia.org/wiki/Paxos_(computer_science)>


Cheers,
simon

Re: Reproducible Builds Summit 2022

[Christopher Baines]

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


zimoun <zimon.toutoune@gmail.com> writes:

> Really cool!  Thank you for the heads-up.
>
> On Thu, 03 Nov 2022 at 15:44, Efraim Flashner <efraim@flashner.co.il> wrote:
>
>>                  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.
>
> I am not a specialist about consensus algorithm so maybe I am totally
> out of topic.  This K-of-N agreement looks like a Proof of Stake [1].

I think it's useful to keep this simple.

Going back to [1], currently we only support users trusting substitutes
if they're signed by any key they trust.

I'd like to see support for more complex policies, like only trusting
substitutes if there's a valid signature from two substitute servers
(two different keys). So trusting substitutes that have been built by
two substitute servers, and they've come to the same result.


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

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

Re: Reproducible Builds Summit 2022, nar support in diffoscope

[Ludovic Courtès]

Christopher Baines <mail@cbaines.net> skribis:

> One thing I forgot to tell Efraim about is that I got around to looking
> at nar support in diffoscope. I know this isn't essential as you can
> just unpack the nars, then compare (as I think guix challenge does), but
> I've been thinking this could make it easier to compare nars.
>
> Anyway, as part of this I proposed adding lzip support, since nars can
> be lzipped, that turned out to be quite easy:
>
>   https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/106
>
> I'm finding nar support a bit harder though, I've raised a merge request
> anyway to see if I can get any feedback:
>
>   https://salsa.debian.org/reproducible-builds/diffoscope/-/merge_requests/107

Nice!  It’s good if that eventually allows ‘guix challenge’ to delegate
that to diffoscope.

Ludo’.