all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Tobias Geerinckx-Rice <me@tobias.gr>
To: zimoun <zimon.toutoune@gmail.com>
Cc: Jonathan McHugh <indieterminacy@libre.brussels>, guix-devel@gnu.org
Subject: Re: Public guix offload server
Date: Fri, 22 Oct 2021 00:16:17 +0200	[thread overview]
Message-ID: <87mtn256it.fsf@nckx> (raw)
In-Reply-To: <867de611ya.fsf@gmail.com>

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

All,

zimoun 写道:
>>> Do you mean that trusted users would try WM-escape exploits?
>> The world has been formed by warewolves inside communities 
>> purposely
>> causing harm. Looking further back, Oliver the Spy is a classic
>> examplar of trust networks being hollowed out.

So…

> I cannot assume that on one hand one trusted person pushes to 
> the main
> Git repo in good faith and on other hand this very same trusted 
> person
> behaves as a warewolves using a shared resource.

…li'l' sleepy here, bewarned, but before this gets out of hand: I 
never implied direct abuse of trust by committers.  I don't 
consider it the main threat[0].

There are the people you meet at FOSDEM and the users who log into 
machines.  Both can be compromised, but the latter are much easier 
and more likely to be.

Such compromise is not laughable or hypothetical: it happens 
*constantly*.  It's how kernel.org was utterly owned[1].

Trusting people not to be evil is not the same as having to trust 
the opsec habits of every single one of them.  Trust isn't 
transitive.  Personally, I don't think a rogue zimoun will 
suddenly decide to abuse us.  I think rogues will abuse zimoun the 
very first chance they get.

That's not a matter of degree: it's a whole different threat 
model, as is injecting arbitrary binaries vs. pushing malicious 
code commits.  Both are bad news, but there's an order of 
magnitude difference between the two.

> For sure, one can always abuse the trust.  Based on this 
> principle, we
> could stop any collaborative work right now.  The real question 
> is the
> evaluation of the risk of such abuse by trusted people after 
> long period
> of collaboration (that’s what committer usually means).

Isn't that the kind of hands-up-in-the-air why-bother 
nothing's-perfect fatalism I thought your Python quote (thanks!) 
was trying to warn me about?  ;-)

Zzz,

T G-R

[0]: That's probably no more than an optimistic human flaw on my 
part and ‘disgruntled ex-whatevers’ are probably more of a threat 
that most orgs dare to admit.

[1]: I know, ancient history, but I'm working from memory here. 
I'm sure it would be trivial to find a more topical example.

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

  reply	other threads:[~2021-10-21 22:59 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
2021-10-21 21:15       ` Jonathan McHugh
2021-10-21 21:51         ` zimoun
2021-10-21 22:16           ` Tobias Geerinckx-Rice [this message]
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=87mtn256it.fsf@nckx \
    --to=me@tobias.gr \
    --cc=guix-devel@gnu.org \
    --cc=indieterminacy@libre.brussels \
    --cc=zimon.toutoune@gmail.com \
    /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.