all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: zimoun <zimon.toutoune@gmail.com>
To: Tobias Geerinckx-Rice <me@tobias.gr>,
	Arun Isaac <arunisaac@systemreboot.net>
Cc: guix-devel@gnu.org
Subject: Re: Public guix offload server
Date: Thu, 21 Oct 2021 10:12:15 +0200	[thread overview]
Message-ID: <864k9ag5k0.fsf@gmail.com> (raw)
In-Reply-To: <87cznz74l5.fsf@nckx>

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


  parent reply	other threads:[~2021-10-21  8:19 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-10-20 20:53 Public guix offload server Arun Isaac
2021-10-20 21:06 ` Tobias Geerinckx-Rice
2021-10-20 22:54   ` Leo Famulari
2021-10-21 16:46     ` Tobias Geerinckx-Rice
2021-10-21  8:12   ` zimoun [this message]
2021-10-21 16:31     ` Tobias Geerinckx-Rice
2021-10-21 18:04       ` zimoun
2021-10-21 21:15       ` Jonathan McHugh
2021-10-21 21:51         ` zimoun
2021-10-21 22:16           ` Tobias Geerinckx-Rice
2021-10-22  7:33             ` zimoun
2021-10-23  5:49               ` Arun Isaac
2021-10-23  7:23                 ` zimoun
2021-10-24  6:43                   ` Arun Isaac
2021-10-25  9:27                     ` indieterminacy
2021-10-22  7:23           ` Jonathan McHugh
2021-10-21 20:23   ` Arun Isaac
2021-10-29 12:04     ` Ludovic Courtès
2021-10-29 12:01   ` Ludovic Courtès
2021-10-20 22:56 ` Leo Famulari
2021-10-21 15:49   ` Joshua Branson
2021-10-21 16:41     ` Tobias Geerinckx-Rice
2021-10-21 17:22     ` Vagrant Cascadian
2021-10-29 12:06       ` Ludovic Courtès
2021-10-29 12:44         ` Tobias Geerinckx-Rice
2021-10-21 23:40     ` jbranso

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=864k9ag5k0.fsf@gmail.com \
    --to=zimon.toutoune@gmail.com \
    --cc=arunisaac@systemreboot.net \
    --cc=guix-devel@gnu.org \
    --cc=me@tobias.gr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.