Re: Public guix offload server

[Tobias Geerinckx-Rice <me@tobias.gr>]

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

Hi Arun,

Arun Isaac 写道：
> If security is a problem with a public access guix offload 
> server, we
> could make it semi-public and available at least to people with 
> commit
> access.

Giving access only to people with commit access is a given, but 
any shared offload server is a huge shared security risk.

Guix is not content-addressed.  Any [compromised] user can upload 
arbitrary malicious binaries with store hashes identical to the 
legitimate build.  These malicious binaries can then be downloaded 
by other clients, which presumably all have commit access.

Now the attacker almost certainly has covert access to one or more 
user accounts that can push signed commits to Guix upstream.

> Currently, guix offload requires mutual trust between the master
> and the build machines. If we could make the trust only one-way,
> security might be less of an issue.

It might!  It's easy to imagine a second, less powerful offload 
protocol where clients can submit only derivations to be built by 
the remote daemon, plus fixed-output derivations.  None of the 
‘let me send the entire binary toolchain so you don't have to 
build it from scratch’ of the current protocol.  This at least 
removes their control over the source hash.

At that point, one might consider dropping SSH account-based 
access in favour of a minimal job submission API, and just return 
the results through guix publish or so…?  OTOH, that's yet another 
code path.

> WDYT? How does everyone else handle big builds? Do you have 
> access to
> powerful workstations?

By waiting, and planning.  I'm lucky to have a ridiculously 
overpowered ThinkPad for its age and a newer headless tower at 
home that can run builds 24/7, but nothing close to a ‘powerful 
workstation’ by industry standards.

Zzz,

T G-R

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