Re: Public guix offload server

[zimoun]

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