guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Public guix offload server


From: zimoun
Subject: Re: Public guix offload server
Date: Thu, 21 Oct 2021 10:12:15 +0200

Hi Tobias,

On Wed, 20 Oct 2021 at 23:06, Tobias Geerinckx-Rice <me@tobias.gr> wrote:

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

If I understand correctly, if a committer offloads to say Berlin or
Bayfront, your concern is that the output will be in the publicly
exposed store.  Right?

If yes, one could imagine two stores: one populated by CI as it is
currently done and another one mounted elsewhere considered as sandbox
and regularly garbage collected.

For instance, one could imagine a dedicated VM for all the committers
who require some CPU power.

I mean, it is some system administration work, but is it not technically
feasible?


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

A minimal job submission API with token would be ideal, IMHO.  But it
falls into:

        Now is better than never.
        Although never is often better than *right* now.

                                    – python -c 'import this' –


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

I sympathize with Arun’s requests.  For instance, it is impossible to
review Julia packages using my old laptop.  Even, it takes ages to just
compile Guix from sources and it is becoming worse and worse.
Hopefully, I am lucky and I have remote access to some workstations at
work.

Yes, we can wait and plan for a better solution for helping committers
to do their review. ;-)


Cheers,
simon



reply via email to

[Prev in Thread] Current Thread [Next in Thread]