Re: Public guix offload server

Ludovic Courtès 写道： Would someone like to contact them on behalf of the project, Cc: guix-sysadmin? :-) I'll do it. They know^Wvaguely remember me from our guix-p9. Kind regards, T G-R signature.asc Description: PGP signature

Re: Public guix offload server

Hi! Vagrant Cascadian skribis: > I wonder if OSUOSL (or maybe other organizations) would be willing to > provide a nice big server with access restricted to guix committers or > something? > > https://osuosl.org/services/hosting/ > > I know they provide some very capable machines for

Re: Public guix offload server

Arun Isaac skribis: > I just realized we might already have something close to this second, > less powerful offload protocol that needs only one-way trust. According > to the NEWS file, since Guix 0.13.0, the GUIX_DAEMON_SOCKET environment > variable lets us specify remote daemons. See "(guix)

Re: Public guix offload server

Hi, Tobias Geerinckx-Rice skribis: > Arun Isaac 写道： [...] >> Currently, guix offload requires mutual trust between the master >> and the build machines. If we could make the trust only one-way, >> security might be less of an issue. > > It might! It's easy to imagine a second, less powerful

Re: Public guix offload server

Hi Arun, Researching git-shell, I noticed an example of how Less could be exploited to increase. privileges: => https://hackaday.com/2017/05/10/git-shell-bypass-less-is-more/ It suggests enabling the no-pty flag to mitigate this. I think it would be great to utilise git-shell (and I am

Re: Public guix offload server

>> $ export GUIX_DAEMON_SOCKET=ssh://char...@sandbox.guix.gnu.org:22 >> $ guix build foo > > …requires an SSH access by ’charlie’ to sandbox.guix.gnu.org, And they > think this access is risky. We could provide SSH access but no shell access. We could use some restricted shell in the spirit of

Re: Public guix offload server

Hi Arun, On Sat, 23 Oct 2021 at 11:19, Arun Isaac wrote: >> Imagine another Cuirass instance where any committer could add [1] their >> own branch. It would act as this minimal job submission API. > I don't think we need Cuirass. We could just use the remote guix-daemon > features that are

Re: Public guix offload server

Hi zimoun, > Imagine another Cuirass instance where any committer could add [1] their > own branch. It would act as this minimal job submission API. > > 1: > > The questions are the authentication to this Cuirass instance and how > Cuirass deals with

Re: Public guix offload server

Hi Tobias, I understand your point of view. On Fri, 22 Oct 2021 at 00:16, Tobias Geerinckx-Rice wrote: > 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

Re: Public guix offload server

I have utmost confidence in the Guix project, it has lots of smart and inquisitive people to suppliment its accountable structures - a very useful bulwark against exploitative behaviour! Jonathan McHugh indieterminacy@libre.brussels October 22, 2021 12:59 AM, "Tobias

Re: Public guix offload server

October 21, 2021 12:44 PM, "Tobias Geerinckx-Rice" wrote: > Joshua Branson 写道： > >> I've got an old Dell Optiplex 7020 with 30 gigs of RAM with a >> 3TB >> hard-drive just sitting around. My landlord and ISP is ok with >> me >> running a server. I just set everything up. Would this be >>

Re: Public guix offload server

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

Re: Public guix offload server

Hi, On Thu, 21 Oct 2021 at 21:15, "Jonathan McHugh" wrote: > October 21, 2021 8:10 PM, "zimoun" wrote: >>> 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). >> >>

Re: Public guix offload server

October 21, 2021 8:10 PM, "zimoun" wrote: > >> 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? >

Re: Public guix offload server

Hi, >> Currently, guix offload requires mutual trust between the master and >> the build machines. If we could make the trust only one-way, security >> might be less of an issue. > > It might! It's easy to imagine a second, less powerful offload > protocol where clients can submit only

Re: Public guix offload server

Hi Tobias, On Thu, 21 Oct 2021 at 18:31, Tobias Geerinckx-Rice 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

Re: Public guix offload server

On 2021-10-21, Joshua Branson wrote: > Leo Famulari writes: > >> On Thu, Oct 21, 2021 at 02:23:49AM +0530, Arun Isaac wrote: >>> WDYT? How does everyone else handle big builds? Do you have access to >>> powerful workstations? >> >> Now I have access to a very powerful system on which I can test

Re: Public guix offload server

Leo, Leo Famulari 写道： Interesting... I'm not at all familiar with how `guix offload` works, because I've never used it. But it's surprising to me that this would be possible. Although after one minute of thought, I'm not sure why it wouldn't be. Very quickly: - You send an offload request

Re: Public guix offload server

Joshua Branson 写道： I've got an old Dell Optiplex 7020 with 30 gigs of RAM with a 3TB hard-drive just sitting around. My landlord and ISP is ok with me running a server. I just set everything up. Would this be powerful/interesting to some? Well, not going to lie: yes. I've heard that US

Re: Public guix offload server

Hi Simon, 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,

Re: Public guix offload server

Leo Famulari writes: > On Thu, Oct 21, 2021 at 02:23:49AM +0530, Arun Isaac wrote: >> WDYT? How does everyone else handle big builds? Do you have access to >> powerful workstations? > > Now I have access to a very powerful system on which I can test builds. > > I agree that the Guix project

Re: Public guix offload server

Hi Tobias, On Wed, 20 Oct 2021 at 23:06, Tobias Geerinckx-Rice 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

Re: Public guix offload server

On Thu, Oct 21, 2021 at 02:23:49AM +0530, Arun Isaac wrote: > WDYT? How does everyone else handle big builds? Do you have access to > powerful workstations? For my first several years with Guix... I handled big builds patience and care. I could have spent a small amount of money on powerful yet

Re: Public guix offload server

On Wed, Oct 20, 2021 at 11:06:05PM +0200, Tobias Geerinckx-Rice wrote: > 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 >

Re: Public guix offload server

Hi Arun, Arun Isaac 写道： If security is a problem with a public access guix offload server, we could make it semi-public and available at least to people with commit access. Giving access only to people with commit access is a given, but any shared offload server is a huge shared security