Re: Public guix offload server

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

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

Leo,

Leo Famulari 写道：
> Interesting... I'm not at all familiar with how `guix offload` 
> works,
> because I've never used it. But it's surprising to me that this 
> would be
> possible. Although after one minute of thought, I'm not sure why 
> it
> wouldn't be.

Very quickly:

- You send an offload request to the offload server, but you also 
  get so send any remotely missing store items that you already 
  have, as opaque binaries (icecat could be tetris instead).

This is why the offload server has to trust your key.  It's 
valuable and shouldn't be removed, but making it optional[0] 
shouldn't be ‘too hard’.

- The offload sends back one or more store items, which is why you 
  trust it.  This part is just substitution in a different form 
  (SSH vs. HTTPS etc.)

> However, the Guix security model trusts committers 
> implicitly. So, if
> the committers' shared offload server had proper access control, 
> one
> might consider it "good enough" in terms of security.

The two are *SO* different as to be incomparable IMO.

You do point out the difference, so I guess we just assess it very 
differently:

> Although the
> possibility of spreading malicious binaries is much scarier than 
> what
> could be achieved by committing to guix.git, because of the 
> relative
> lack of transparency.

Gotta run,

T G-R

[0]: Which would create the

  “second, less powerful offload protocol where clients can submit
   only derivations to be built by the remote daemon, plus
   fixed-output derivations”

I imagined.  But this is still hand-waving at this point.  :-)

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