From: zimoun <zimon.toutoune@gmail.com>
To: Tobias Geerinckx-Rice <me@tobias.gr>
Cc: guix-devel@gnu.org
Subject: Re: Public guix offload server
Date: Thu, 21 Oct 2021 20:04:05 +0200 [thread overview]
Message-ID: <864k9a2r1m.fsf@gmail.com> (raw)
In-Reply-To: <87a6j272oz.fsf@nckx>
Hi Tobias,
On Thu, 21 Oct 2021 at 18:31, Tobias Geerinckx-Rice <me@tobias.gr> wrote:
> zimoun 写道：
>> 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?
>
> No, that would be far worse. I'm considering only a ‘private’
> offload server shared by several trusted users, where one
> compromised (whether technically or mentally :-) user can easily
> ‘infect’ other contributors in a way that's very hard to detect.
> ‘Trusting trust’ comes to mind.
Thanks for explaining.
Unseriously, I do not the see the difference when several trusted users
push to a Git repo, where one compromised user can easily ’infect’ other
contributors in a way that’s very hard to detect. ;-)
If a compromised user offloads something, how other users of the same
server would get this compromised stuff? Maybe I miss something.
Considering trusted users (i.e., not conscientiously malicious), the
surface of the attack is reproducible builds; similarly to the current
situation of substitutes by CI. What do I miss?
Well, I do not see the difference between a remote offload server and a
shared store on cluster (although probably worse because many users – at
least some of I know – of clusters often do not really understand what
they do when using Guix ;-)).
> Now, we could spin up a separate VM for each user, and just take
> the efficiency hit… Users would be safe from anything but
> VM-escape exploits (which exist but are rare).
Do you mean that trusted users would try WM-escape exploits?
>> 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' –
>
> What does this mean?
It is The Zen of Python. :-) These sentences express the complexity of
the right balance, IMHO. Sorry if it was unclear. Otherwise, the
complete Zen reads:
--8<---------------cut here---------------start------------->8---
$ python -c 'import this'
The Zen of Python, by Tim Peters
Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
--8<---------------cut here---------------end--------------->8---
Cheers,
simon
next prev parent reply other threads:[~2021-10-21 18:11 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
2021-10-21 16:31 ` Tobias Geerinckx-Rice
2021-10-21 18:04 ` zimoun [this message]
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
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=864k9a2r1m.fsf@gmail.com \
--to=zimon.toutoune@gmail.com \
--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 public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).