U.S. Midwest based build farm

U.S. Midwest based build farm

[jbranso]

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

Hey guix,

I live near a big university that sells old Dell 7020 optiplex machines. So each desktop machine costs about $200 - $250, depending on how the current market rate is for hard drive and RAM. My current landlord has an unused basement. It should be somewhat easy to get an ethernet cord to the basement, plugged up to 2+ desktop machines. My ISP is metronet, which is usually pretty friendly to self-hosting things. If guix is interested in paying for some of the ISP bills, electric bills, and/or renting my landlord's basement, I think it would be pretty cool to try to set up another build farm.

Why I am the best candidate for this role:

I'm not. I have a pretty bad track record for being lazy. I have still not finished my opensmtpd configuration for the opensmtpd service.

What do you all think?

What's good and/or bad about this idea?
Thanks,

Joshua

[-- Attachment #2: Type: text/html, Size: 1180 bytes --]

Re: U.S. Midwest based build farm

[Maxime Devos]

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

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’?

Other points: ...?

Greetings,
Maxime.

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: U.S. Midwest based build farm

[Vagrant Cascadian]

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

Re: U.S. Midwest based build farm

[jbranso]

June 11, 2022 4:00 PM, "Maxime Devos" <maximedevos@telenet.be> 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, ...?

That's actually a good idea.  I could give limited ssh access to a few
guix developers.  Those guix developers could use my old and hopefully 
more powerful machines to quickly compile software.  Rust takes ages
to compile...

> 
> 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’?
> 

Thanks for the feedback.  We could also use the machines as a mirror
or an additional substitute server.  

> Other points: ...?
> 
> Greetings,
> Maxime.