IRC channel logs

<euleritian>I was looking forward to Christines FOSDEM talk for weeks, and I while did enjoy it quite a bit, I have to admit that I didn't learn any more details than before. Somehow, guix should use gobblins, that will be completely new and improve everything. But... how? Does guix get a new architecture? Will guix be rewritten in gobblins? Are all guix developers fine with that? Was this a topic during the guix days? Will the daemon

<euleritian>need to change? How is the shepherd involved? Will guix still work on foreign distros? Is gobblins up to the task already? Is there a roadmap?

<dthompson>euleritian: I wasn't there but I believe things were discussed in much more detail at guix days. 20 minute talks are tough...

<dthompson>I can try to add some detail based on what I know

<dthompson>in guix there are several components that involve inter-process or inter-machine communication: the build daemon and shepherd being the two biggest pieces.

<dthompson>right now they use custom protocols that have their limitations, especially security-wise.

<dthompson>by using goblins, they could all talk over the same protocol, OCapN, which would also provide a very strong security model

<dthompson>shepherd was pretty recently improved to use an actor-like model to make it more reliable and resilient to failure

<Zarutian_iPad>reminds me, the ocapn meeting is next tue (not this but from week from now)

<dthompson>so going all-in on actors with shepherd isn't such a big lift

<dthompson>the abstraction layer goblins provides enables components of the system to be moved across many machines, so it will allow guix tools to easily work in a distributed system. this would be helpful for build farms, deployments, substitute servers, etc.

<jfred>The audio/camera on the stream unfortunately cut out just as Christine was getting to the Guix-related stuff 😅 I'm hoping that it's in the recording

<dthompson>with guix + goblins, we can begin building a capability secure operating system on top of linux

<jfred>wish I could've made it to Guix Days for that

<dthompson>an initial guix + goblins integration would probably not be visible to the average user. the high-level architecture of guix wouldn't really change.

<dthompson>but it would enable lots of cool things to happen that would be user visible.

<dthompson>right now there's a partition between system services and home services, with an ocap based system they could be unified

<dthompson>guix would still work on foreign distros. if guix had to sacrifice something like that it wouldn't be worth doing.

<dthompson>goblins is not quite up to the task yet, but it's not far off, either. one key missing piece is an ocapn netlayer that works over unix domain sockets. at the very least shepherd needs that.

<dthompson>there is no roadmap as this is all still in the "cool idea" phase

<dthompson>I don't know many core guix people are on board, but ludovic, the creator of guix, is very enthusiastic about it.

<dthompson>okay that should hopefully answer a lot of those questions :)

<dthompson>the fosdem talks were so short so our talk was more of a call to action and trying to get the ball rolling and invite collaborators

<dthompson>in other news, I have 80% of the r7rs benchmark suite working in hoot... getting there

<parnikkapore_x>unifying system & home services cleanly sounds interesting! I'd be interested to hear about how Goblins helps here

<dthompson>parnikkapore_x: imagine if all services ran in some sort of container and were given their necessary inputs: a file system to write to, a binary to run, etc.

<dthompson>rather than the current system where a system service is assumed to have root privileges and thus can do whatever it wants, usually running some daemon as an unprivileged system user account

<parnikkapore_x>ah, that does sound helpful for shepherd services!

<dthompson>in a way, the existence of guix home is kind of unfortunate. we really just want to run the same stuff with different sets of capabilities

<parnikkapore_x>(I'm more thinking about how to deal with e.g. home-profile-service-type, which doesn't quite translate well to system services)

<dthompson>I'm using daemons as an example, it applies the same to all types of services

<dthompson>every service does some task with some inputs.

<dthompson>the home profile service could receive a capability to modify a user's current guix profile

<parnikkapore_x>I'll think about it; thanks!

<dthompson>everything is a function :)

<jfred>The ocap-y thing that I've been thinking about most re: Guix is composition of services across machines. Like for example linking an application server on one machine to a database server on another. Under the hood that might still involve username/password auth via some network tunnel due to the underlying software support, but I feel like those connections could be modeled with capabilities in the deployment system.

<jfred>Of course Guix stores most stuff in the store which is world-readable, so handling credentials is difficult...

<euleritian>dthompson: Thank you!

<dthompson>jfred: credentials aren't particularly difficult, but it does cause confusion because people always want to put them in the store. credentials are state. they are something that have to be obtained at "runtime", not system configuration time.

<jfred>hmm

<jfred>Perhaps, but... when a machine comes back online, it needs a way to obtain those credentials if it doesn't have them stored persistently. And most mechanisms I know of to do that involve at least some credentials themselves

<dthompson>are you familiar with credential services like aws secrets manager?

<jfred>(unless you're running on a cloud platform with instance identity/IAM systems or similar)

<dthompson>there are a range of solutions that fit various scales. for simple things, manually entering the credentials on the relevant machine is enough.

<dthompson>larger systems need automation like what the cloud platforms have

<dthompson>there's always a bootstrapping step, but the details depend on the scale

<jfred>The world I live in tends to be somewhere in between, where you're on a smaller platform that doesn't have a platform-level IAM equivalent but you're past the point where manually entering credentials is practical

<dthompson>at the personal server scale, you can bootstrap with either a pre-configured OS image that accepts your SSH key (for example) or use the web shell to add it. of course you wouldn't want to do this for a large fleet of servers.

<dthompson>yeah I think there needs to be better tools for this medium scale

<dthompson>there needs to an easily self-hostable credentials service and a way to pre-authenticate servers with it

<dthompson>I understand why there's a gap, people doing stuff at a small scale just do the simplest thing which is usually a manual process and large scale organizations buy-in to a giant cloud provider and have a huge complicated thing they can use.

<jfred>Even at the personal server scale though, I don't necessarily want to have to take manual action whenever a machine reboots. I could imagine a Goblins-based handshake system where a machine has some way to signal to a credential service "hey I just rebooted" and the credential service then sends back the credentials for that machine. But... that capability to get credentials is itself a credential, and needs to be stored somewhere

<dthompson>why would you have to take manual action when a machine reboots?

<dthompson>I don't have to tell my server to trust my ssh key when I reboot it

<dthompson>the bootstrap process should be a one time occurrence.

<dthompson>ec2 instance profiles are kinda sorta like a capability that pre-auths the server to communicate with the aws apis covered by the associated iam policy

<jfred>Mmm... I guess I was thinking of things like what NixOps does, which I think requires that you run `nixops send-keys` after a reboot by default as it deploys to non-persistent storage. But I suppose it doesn't *have* to do that

<dthompson>I haven't kept up with nixops for several years but I was not a fan of its architecture when I looked at it years ago prior to mentoring the GSoC that added 'guix deploy'

<jfred>Wherever you store them on disk though you do have to ensure that only the things you want to be able to read them are able to. I suppose that's more straightforward if, as you mentioned above, all services were running in containers

<dthompson>yeah now we're in classic unix file permission nonsense :)

<jfred>Yeah. So it'd be nice if a given Guix service could have a capability to read whatever credentials it might need :P

<dthompson>we can use linux namespaces to isolate as much as is possible. it's bound to be leaky because we're trying to build ocaps on top of acls but it would be much better than the status quo

<dthompson>guix has call-with-container which provides an interface to all that stuff

<jfred>(I wonder, would any of this be easier to implement on the Hurd than on Linux? I know it's at least somewhat capability-based but seem to recall it falls back to ACLs for file permissions on disk)

<dthompson>yeah hurd is a much better platform in theory

<dthompson>microkernel, much stronger isolation properties

<jfred>I've not looked into it in as much detail as I'd like to

<dthompson>but for practical purposes you really have to build something that can run on linux

<jfred>fair enough, haha

<dthompson>guix runs on linux and hurd, so this theoretical abstraction layer could work on both

<jfred>As to the point about people using large cloud providers having a big complex thing they can use for credential management... it's true, but from what exposure to that I have you end up in ACL hell a bit haha

<jfred>I've not used AWS's secrets management tools, but I've used Hashicorp Vault a bunch, and defining policies with anything approaching least-privilege is painful

<dthompson>yeah it's all trash from that perspective

<jfred>which is why I've been noodling on more capability-style replacements for things like that

<dthompson>there is not much in the mainstream that has the security properties we want, hence spritely's existence :)

<jfred>indeed :)

<dthompson>but there's good(ish) architecture details to be taken from existing systems

<dthompson>things that fully use ocaps don't need any of this credential service nonsense

<jfred>Mostly, but cross-machine capabilities that need to persist across restarts need to be serialized as sturdyrefs, yeah? And those are effectively credentials

<jfred>in the sense that they need to be stored *somewhere* safely

<dthompson>yeah persistence is necessary

<dthompson>we're working on it

<jfred>But yeah, maybe even a thin capability-style wrapper could avoid the need for a credential service if you can safely store sturdyrefs. I could imagine a mysql proxy object that accepts a `get-creds` method call, and returns a connection string for the caller to use

IRC channel logs

2024-02-05.log