<nixbitcoin>
Hey, how do you guys deal with nixpkgs expression integrity?
<MichaelRaskin>
Not even close to caring about that
<nixbitcoin>
You mean it's too early in the development?
<nixbitcoin>
Or you just don't care in general?
<Irenes[m]>
I would assume it's too early in development
<MichaelRaskin>
It is _way_ too early in development
<Irenes[m]>
I would note that there are a lot of things you can do on top of base NixOS that should work just as well on SpectrumOS
<Irenes[m]>
for example, you can have a local checkout of nixpkgs and verify signatures on it before making it visible to your machines
<MichaelRaskin>
Well, VM-to-VM communication and some level of GUI isolation is indeed needed
<Irenes[m]>
they do require you to do your own development
<Irenes[m]>
ah, yeah
<nixbitcoin>
Irenes: Which signatures could one verify? On merge commits by maintainers?
<MichaelRaskin>
And once that exists, I am definitely not going to care about the SpectrumOS management layer, and will just replace nsjail with the better solution
<Irenes[m]>
nixbitcoin: I believe they use signed tags
<MichaelRaskin>
nixbitcoin: there is not even close to a complete set of signatures
<Irenes[m]>
I'd have to check
<nixbitcoin>
Yes, there really isn't
<nixbitcoin>
with our project we are doing the bare minimum checking signatures on merge commits against a "trusted" list of maintainers
<nixbitcoin>
But all that tells you is that such a maintainer had the tree hash locally
ehmry has joined #spectrum
<Irenes[m]>
right. I mean, it's a hard problem.
<MichaelRaskin>
We-ell
<MichaelRaskin>
Doing much better than will ever be convenient in Git is not
<MichaelRaskin>
Monotone did it before Git existed
<Irenes[m]>
what did Monotone do
<nixbitcoin>
I thought Lance R. Vick put out an rfc proposal for exactly this a while back
<nixbitcoin>
MichaelRaskin: Yes what did monotone do?
<MichaelRaskin>
Well, in monotone everything is signed by some key.
<MichaelRaskin>
(and you even have server ACLs based on the same keys)
<Irenes[m]>
(since you're new here I should explain that I am not a SpectrumOS developer and have zero power to make any changes. I'm just a fan.)
<nixbitcoin>
Haha, thanks for the disclaimer
<Irenes[m]>
sure thing
<MichaelRaskin>
So if a commit is claimed to be done by someone with a track record, it was at least done by someone who at some point had more or less full user-level access to their $HOME
<nixbitcoin>
Irenes[m]: I want to study this project more closely as well. In nix-bitcoin, a Bitcoin node based on nixos, we basically use standard linux discretionary access control and extensive systemd hardening to protect our services (and thereby funds)
<nixbitcoin>
But spectrum is taking it to a whole new level
<MichaelRaskin>
nixbitcoin: well, you might be better served by firecracker than CrosVM
<nixbitcoin>
MichaelRaskin: Does monotone support hardware keys for signing?
<Irenes[m]>
process isolation
<MichaelRaskin>
Not sure.
<Irenes[m]>
Spectrum is about a specific set of changes, at least right now
<Irenes[m]>
I will note that it is mostly end users who are going to have this need. if you want to sandbox an app that doesn't need the GUI, you can already put it in VM. it won't be perfect - most VMs aren't really that hardened - but it's better than you can achieve for GUI apps today.
<MichaelRaskin>
(but full $HOME access almost always means ability of manipulating the state just pre-commit)
<Irenes[m]>
(my messages seem to have been transmitted out-of-order, sorry about that)
<Irenes[m]>
I would hope that your cryptocurrency stuff isn't running on machines that people are doing end-user app stuff on
<MichaelRaskin>
SpectrumOS will not even try to ship better VM-level isolation than CrosVM in nsjail, in any foreseeable future
<Irenes[m]>
right, I just mean CrosVM is hard for anyone to use right now because it's hard to build
<MichaelRaskin>
You might get some benefit once VM-to-VM networking is feasible with less interaction with the host network stack
<Irenes[m]>
I think making clean nix packaging for it is a significant contribution even without the other stuff
<MichaelRaskin>
Well, Now it is there in Nixpkgs
<Irenes[m]>
very fair!
<Irenes[m]>
yay for upstreaming stuff
<nixbitcoin>
So, spectrum is more focused on secure desktop environments?
<Irenes[m]>
you can read an exact description of the innovations that are being developed right now, on the website
<Irenes[m]>
and yes
<Irenes[m]>
qyliss is the only one who can speak authoritatively about future plans, as far as I know
<MichaelRaskin>
Yes
<nixbitcoin>
Ok, as I said, I'm interested and I need to read more, but I was just thinking about the expression integrity problem and wanted to hear what you're up to in that regard
<Irenes[m]>
it's a hard problem for sure
<nixbitcoin>
Having some kind of client-side-verified multi-signature logic would be very cool but add a lot of overhead to the development process
<Irenes[m]>
I'm not sure how you would integrate that with a continuous release process
<nixbitcoin>
On every merge commit into master
<Irenes[m]>
also, I suspect that the capacity to produce cryptographic signatures already far exceeds the capacity to vet every single commit for security purposes
<Irenes[m]>
signing every merge commit doesn't do what you want: it doesn't keep a state actor from slipping in a backdoor
<nixbitcoin>
haha
<nixbitcoin>
very fair
<Irenes[m]>
just saying :)
<MichaelRaskin>
And we are pretty omnivorous about upstreams…
<nixbitcoin>
Do you mean stuff like rust cargo and npm?
<MichaelRaskin>
You probably need to re-audit everything just on the issue of dropping optional dependencies anyway
<MichaelRaskin>
We tend to be very lenient with including support for optional features
<nixbitcoin>
Ugh, I hate it. We closely study our colleagues every commit and then blindly trust upstream shit.
<Irenes[m]>
I actually looked at the NixOS package for the Signal desktop app the other day, and realized that it's using upstream binaries
<Irenes[m]>
via the upstream .deb, which it pulls apart and reorganizes
<MichaelRaskin>
Nixpkgs is about building a large fraction of consumer free software out there
<nixbitcoin>
I like OpenBSD's approach. Reduce, reduce, reduce attack surface and be slightly different than everyone else to buy more time patching stuff.
<Irenes[m]>
so I concluded that I don't feel comfortable using it, personally, because I think that upstream binaries shouldn't be trusted for people who have serious threat models
<MichaelRaskin>
Irenes: casuistically, Signal ToS doesn't allow to connect to the official server using clients self-built from official sources
<Irenes[m]>
sure
<nixbitcoin>
Can there be a more vetted nixpkgs tree and a type of NUR for all the fly-byers?
<Irenes[m]>
which is just what I would want if I were the NSA
<MichaelRaskin>
Signal is just horrible all-around
<MichaelRaskin>
_only_ phone-based identities
<Irenes[m]>
nixbitcoin: I mean you'd have to start by auditing all the compilers, every single commit
<MichaelRaskin>
_only_ smartphone-first
<Irenes[m]>
there are not a whole lot of engineers out there who are competent to do that, even if it could be completed in a human lifetime
<Irenes[m]>
MichaelRaskin: I agree but this is getting far afield
<MichaelRaskin>
_completely unbelievable_ battery drain if there are no Google Services
<Irenes[m]>
I was just trying to illustrate that trusting your OS is hard
<nixbitcoin>
MichaelRaskin: Sorry to go off-topic but what do you personally like instead of Signal?
<nixbitcoin>
XMPP+OMEMO?
<Irenes[m]>
oh there isn't anything good lol
<MichaelRaskin>
Irenes: you kind of have a chance of reducing it to auditing every commit to CompCert _spec_ and to the prover system core
<Irenes[m]>
I don't think there ever will be anything good until we do away with the model where everything is developed by corporations
<nixbitcoin>
Has anyone ever tried building a completely audited system?
<Irenes[m]>
corporations sit within the system of capitalism, which means they sit within the system of authoritarian state power
<MichaelRaskin>
nixbitcoin: in many cases it is worse than self-hosted without e2ee
<Irenes[m]>
they will never give you everything you need to go outside that system
<Irenes[m]>
because their own existence would be threatened
<Irenes[m]>
they will always make some small compromise somewhere
<Irenes[m]>
aimed at making you feel that they did all they could
<nixbitcoin>
NO COMPROMISES
<MichaelRaskin>
nixbitcoin: well, we do know that at the mass-deployment level even nation-states fail at it
<Irenes[m]>
right, so anyway, you shouldn't be looking at OSes that package non-copyleft software if you want that
<Irenes[m]>
at the very least
<nixbitcoin>
worse than self-hosted without e2ee: what is this referring to?
<Irenes[m]>
honestly copyleft isn't strong enough for that but it's a start
<nixbitcoin>
mass-deployment level: What about the BSDs?
<MichaelRaskin>
nixbitcoin: to Signal. XMPP, Matrix, IRC with SSL, whatever.
<nixbitcoin>
monotone: haha I just remembered, the only project I ever saw using monotone was the java implementation of i2p
<MichaelRaskin>
nixbitcoin: I think at some point US failed to track the full supply chain on the hardware level after trying
<Irenes[m]>
and I've been told that focusing on only software trust is missing a lot, because modern chip fabrication methods make it possible to completely change the function of a chip even after the die is finalized
<Irenes[m]>
necessarily so, for debugging purposes
<Irenes[m]>
anyway I am not trying to say that security is futile
<Irenes[m]>
if you have that kind of need you should be spending millions of dollars a year on development efforts to meet it
<Irenes[m]>
if you have that kind of need and don't have that kind of money, though, you're kind of screwed
<nixbitcoin>
What about building super-simple systems like Bitcoin hardware wallets for sensitive operations and then using the computers only for networking of encrypted messages?
<Irenes[m]>
I mean I've never seen a Bitcoin hardware wallet that didn't get compromised eventually
<Irenes[m]>
but you do want to think about things like that
<Irenes[m]>
and it's meaningful if it's part of a full, multi-layered strategy
<Irenes[m]>
with protections that reinforce each other
<nixbitcoin>
mmmh, that sounds good
<MichaelRaskin>
Start with asking can you trust your fab
<Irenes[m]>
isolating components from each other is good
<MichaelRaskin>
If you are talking hardware
<Irenes[m]>
limiting the damage a component can do is good
<Irenes[m]>
MichaelRaskin: indeed...
<MichaelRaskin>
Because it is currently common knowledge that you can play with doping levels and get a die that is undistinguishable under most moderately-expensive checks but has an extra exploitable bug
<Irenes[m]>
yeppppp
<Irenes[m]>
I mean one thing you could do is buy vintage hardware that's decades old
<Irenes[m]>
and assume that any vulnerabilities in it are not things targeted at you specifically
<Irenes[m]>
but like
<Irenes[m]>
that's risky for lots of reasons, in its on right
<nixbitcoin>
Do thinkpads count as vintage hardware?
<Irenes[m]>
and you'll never do cryptocurrency on it for performance reasons
<Irenes[m]>
I wouldn't think anything x86-based is a good idea
<MichaelRaskin>
Anyway, SpectrumOS _starts_ by saying «we know Xen is slightly safer than KVM, but Qubes exists and Qubes-Nix code exists and let's consider the case where Qubes is too much pain»
<Irenes[m]>
CISC is hard
<MichaelRaskin>
There is no RISC anyway
<Irenes[m]>
yeah fair
<Irenes[m]>
in summary
<Irenes[m]>
computers were a mistake and nobody should use them
<MichaelRaskin>
But basically Meltdown-grade carelessness of Intel started around Pentium
<nixbitcoin>
:D
<Irenes[m]>
yeah. I mean, I get it. profit margins are an incentive to be careless.
<Irenes[m]>
and I know people who work at Intel and I want to be very clear that my problem is not with the engineers, it's with the C-suite.
<Irenes[m]>
and I have similar complaints about every multinational corporation.
<MichaelRaskin>
I think when AMD understood there is not _just_ Spectre that everyone had but also Meltdown, they were «wait, you are allowed to be _that_ reckless?»
<Irenes[m]>
yeah :(
<nixbitcoin>
Hmm, shouldn't profit motivate you to serve your customers as well as possible?
<MichaelRaskin>
Nope
<MichaelRaskin>
Profit motive means the best case is monopoly abuse
<MichaelRaskin>
Intel did pay laptop manufacturers for exclusivity
<nixbitcoin>
SpectrumOS: What about headless server stuff? Who fills that gap? Qubes surely doesn't.
<Irenes[m]>
I mean the reality is that there are only a few companies out there with the expertise and the customer base to realistically be able to afford to develop novel processor cores
<MichaelRaskin>
Second best bet is to make sure customers cannot verify quality
<Irenes[m]>
licensing ARM doesn't count, unless you're ARM (or Apple, who do have the expertise to do their own custom stuff)
<Irenes[m]>
so if you want something better than Intel or AMD or ARM... there is nowhere else to go
<MichaelRaskin>
Well, Power
<nixbitcoin>
OPENPOWER9?
<Irenes[m]>
nixbitcoin: your best bet, given that apparently the SpectrumOS CrosVM stuff did get upstreamed, is to try to use CrosVM on the server
<MichaelRaskin>
Actually, expertise to develop is not _that_ scarce
<Irenes[m]>
in my opinion
<Irenes[m]>
that's fair about not that scarce
<Irenes[m]>
I guess I meant, like... you can't do it as one person
<Irenes[m]>
you need a team of a few hundred
<MichaelRaskin>
Fabs are the crazy stuff
<Irenes[m]>
huh. fair!
<Irenes[m]>
not a world I know that much about, despite how I talk
<nixbitcoin>
I thought you had it all figured out with the multinationals and capitalism :D
<Irenes[m]>
I was one of the Google labor organizers, you can look me up, Irene Knapp.
<Irenes[m]>
the political problem and the technical problem are different ;)
<MichaelRaskin>
It may be that for servers Firecracker is more suitable than CrosVM
<Irenes[m]>
and I definitely think it's important to stay humble and remember that I don't know the final answers to anything
<nixbitcoin>
Firecracker: Ok I'll take a look at it
<nixbitcoin>
Have you looked at bubblewrap?
<nixbitcoin>
Irenes[m]: stay humble! amen
<MichaelRaskin>
bubblewrap: I use nsjail instead
<MichaelRaskin>
Irenes: don't you believe in Larry Wall's claim that hubris is one of the programmer's virtues?
<MichaelRaskin>
nsjail/bubblewrap/firejail/unshare have that problem in relying on namespaces which are a tricky and cross-cutting concern, and Linux was not initially designed to support it well.
<Irenes[m]>
I maintain a paradox of confidence and humility.
<MichaelRaskin>
I do think it is much better to run all my browser instances inside namespace jails than without.
<Irenes[m]>
The confidence is for when I'm doing heads-down work
<MichaelRaskin>
But the security of namespacing is known to be imperfect
<Irenes[m]>
or for architectural or strategic decisions, only after I've listened to everyone else
<MichaelRaskin>
And most of the time worse than VMs
<Irenes[m]>
don't get me started on browsers... at some point when I work through my backlog of other commitments, I want to develop Firefox extensions that actually break adtech
<Irenes[m]>
I was on Google's advertising privacy team so I know how to do that
<MichaelRaskin>
It would be counter to self-confidence to pass up on your well-honed skill of extracting information from what people say!
<Irenes[m]>
most things that people try, do not achieve that. up to and including clearing cookies every fifteen seconds.
<Irenes[m]>
exactly!
<MichaelRaskin>
Irenes: I have a belief that the easiest way to break ad-tech is to manage to coordinate adtech fraud on a scale that would lead to auto-banning of entire countries
<Irenes[m]>
ever read _Dirk Gently's Holistic Detective Agency_? it has this concept of an "electric monk", a device designed to believe things for you. for when you need to believe contradictory things.
<Irenes[m]>
MichaelRaskin: you won't achieve that. Google is well ahead of it.
<MichaelRaskin>
Nope, I haven't
<Irenes[m]>
plus you'd go to jail, which is a downside of any plan
<MichaelRaskin>
Go to jail on what charges?
<Irenes[m]>
in the book as in real life, humans don't need electric monks because we're naturally skilled at believing contradictions
<Irenes[m]>
I think it's an important skill sometimes, when used carefully
<MichaelRaskin>
Fake clicks and fake reports seem to be exploited regularly, and that's mere ToS violations
<Irenes[m]>
yeah but you won't succeed in scaling it the way you want to
<Irenes[m]>
and they wouldn't ban a country unless you managed to do it in a way which couldn't be shut down any other way
<Irenes[m]>
which is unlikely
<Irenes[m]>
I won't say they've never banned a country; they mostly do that when laws get passed that make it too hard for them to make money
<Irenes[m]>
I would encourage getting involved in your local politics and campaigning for sufficiently strong laws
<Irenes[m]>
although I know others here will say that working within the system like that is self-defeating, and I respect that
<MichaelRaskin>
Well. «local» is complicating in my case
<MichaelRaskin>
As residence and citizenship do not coincide.
<Irenes[m]>
(but also, that's mostly temporary when they do those bans, and you can view it as a negotiating tactic trying to get more favorable laws passed, and it often works)
<Irenes[m]>
yeah I hear that
<MichaelRaskin>
And my home country politics… well, it's Russia
<Irenes[m]>
oh.
<Irenes[m]>
yes.
<Irenes[m]>
grats on being elsewhere, I think. speaking as a queer person, at least.
<MichaelRaskin>
I think the best description of its current Internet politics is «They started blocking Telegram. Skype degraded more than Telegram»
<Irenes[m]>
yeah.
<Irenes[m]>
so anyway as far as identifying pieces of the problem that are small enough to work on
<MichaelRaskin>
They have recently managed to send demands to _Delta Chat_
<Irenes[m]>
I do think that it would be possible to build browser extensions that provide real privacy guarantees
<Irenes[m]>
although it sucks because like
<Irenes[m]>
it would run into the same issue that all the classical hard-line ad blockers did: all the ad industry has to do is offer them money to break their principles
<Irenes[m]>
and the people who do compromise will then have money, with which to self-promote
<Irenes[m]>
and the people who don't compromise, won't, and will be doomed to obscurity
<Irenes[m]>
so like
<Irenes[m]>
fuck capitalism?
<Irenes[m]>
but yeah
<Irenes[m]>
at least it could exist, even if wide adoption won't happen
<Irenes[m]>
I was not previously familiar with Delta Chat. What did they do to it exactly?
<MichaelRaskin>
Well, Delta Chat is very intrigued by what exactly Russian officials are planning to do
<MichaelRaskin>
Because Delta Chat is an _IMAP client_
<Irenes[m]>
!
<MichaelRaskin>
That happens to provide a e2ee chat UI instead of traditional email UI
<Irenes[m]>
cute trick
<Irenes[m]>
I'm against that on technical grounds, but never mind
<MichaelRaskin>
I mean, it does help with federation and discovery
<Irenes[m]>
yeah
<Irenes[m]>
fair
<MichaelRaskin>
So, they got requests about this key escrow for data relating to users and about data locality
<Irenes[m]>
right.
<Irenes[m]>
that's the obvious thing for a state to demand.
<MichaelRaskin>
And they answer that they are not even a communication service about Russia's own definition
<Irenes[m]>
lol
<MichaelRaskin>
And now I wonder what happens
<MichaelRaskin>
I mean, they could block Delta Chat's project web site
<Irenes[m]>
I mean at this point I don't know that any government anywhere has the ability to protect individuals from the Russian government if they're really pissed
<MichaelRaskin>
Look, do not think of Russian government as of monolith
<Irenes[m]>
sorry, fair
<Irenes[m]>
that makes sense
<MichaelRaskin>
I mean, if it is Yandarbiev then sure.
<MichaelRaskin>
But that's state security people
<Irenes[m]>
that makes sense.
<Irenes[m]>
I apologize, I was taking an overly simplistic view, I know better
<MichaelRaskin>
Note that Roscomnadzor doesn't even claim authority to fine users of non-compliant VPN services
<MichaelRaskin>
(they could have claimed such authority despite not having it by law, happens all the time in Russia, but they officially recognise)
<Irenes[m]>
yes we see
<MichaelRaskin>
So sure, routing blocking, maybe payment blocking — that's on the table
<Irenes[m]>
that's actually incredibly cute about not being a communication service
<MichaelRaskin>
There is also the fun story that they tried to hire someone competent enough to estimate what is the most feasible way to degrade Telegram cheaply
<Irenes[m]>
like word games aren't a long-term strategy but they can be powerful as a short-term one
<Irenes[m]>
haha, oh?
<qyliss>
In regards to server operating systems, I actually have a lot of ideas for how that should work. Firecracker isn't really enough.
<Irenes[m]>
oh I would love to hear about that
<qyliss>
Spectrum is one realisation of what I overall see as the future of computing generally
<qyliss>
And I hope that some core of Spectrum can go on to be something more generally useful
<MichaelRaskin>
Well, VM-to-VM is definitely currently a hard thing, and thanks for making it simpler for others
<qyliss>
I'm trying to avoid making things too concrete right now because I don't need even more things to do when I have grant milestones to achieve
<Irenes[m]>
@qyliss: in your opinion, is CrosVM more secure than Xen and KVM?
<qyliss>
I'm also going to ping edef here because we have something of a shared vision
<Irenes[m]>
haha yeah understood for sure!
<qyliss>
Irenes[m]: crosvm is KVM
<Irenes[m]>
please focus on meeting your grant milestones so you can keep doing this
<Irenes[m]>
ah nod
<qyliss>
I'm not qualified to assess KVM, other than that it seems to be Good Enough
<qyliss>
And most of the threat to KVM that we know of comes from hardware issues
<Irenes[m]>
but yeah I definitely see important ideas in SpectrumOS, my enthusiasm for it is both because of what you're building right now and because of the long-term possibilities
<qyliss>
Which I think is evidence it's doing a pretty decent job.
<Irenes[m]>
that makes sense
<qyliss>
Hardware issues aside (which I can't do anything about), isolation is in a pretty good place
<qyliss>
(Except when people try to use containers for isolation, which they should not)
<qyliss>
At least, isolation where there are security concerns.
<qyliss>
The interesting part is making isolation something that is actually tolerable to use
<qyliss>
That's where Qubes falls down for me
<qyliss>
And, like, sure, my server could be a bunch of containers running in Firecracker, but administering that as a single person would be a nightmare
<Irenes[m]>
makes sense to me
<qyliss>
What Spectrum aims to provide is a single configuration root for managing isolated units
<qyliss>
So you configure your system as a single system, but it then runs as if it were many
<MichaelRaskin>
Hm
<Irenes[m]>
yes, that seems exciting to me
<qyliss>
And that's how I think we should be running servers as well, at least when you're below the scale of having a seperate team to provide servers to you as infrastructure
<Irenes[m]>
that's how the big cloud providers do run their servers
<qyliss>
So the problem is much the same. Isolation is a desirable feature from a maintainability point of view as well as a security one. That's why containers are cool.
<MichaelRaskin>
That actually sounds like something suitable for (non-interactive-shell) servers
<qyliss>
But the way the problems manifest is very different between desktops and servers
<MichaelRaskin>
By now I find isolation desirable from usability point of view, to be fair
<qyliss>
In desktops, the hard problems are all about making isolation boundaries dynamic
<MichaelRaskin>
Yes
<qyliss>
You don't want to have to list every file LibreOffice is allowed to see up front, or just give it either blanket clipboard monitoring permissions or no clipboard access at all
<qyliss>
You want to do that on the fly
<Irenes[m]>
right
<qyliss>
On a server, that's not so much of a problem. The problem there is state management.
<Irenes[m]>
let me tell you sometime about the privacy issues with font files
<Irenes[m]>
anyway, yeah
<MichaelRaskin>
I would say that for a LibreOffice _instance_ you can typically decide on start what it should see
<qyliss>
Possibly, but I don't think it's ideal
<qyliss>
But I don't want to get into that too much right now. I want to talk about servers.
<Irenes[m]>
I agree with qyliss
<qyliss>
Managing persistent state on a single server is a nightmare.
<qyliss>
Even with NixOS. What do I need to back up? What's machine specific?
<qyliss>
NixOS's promises of atomic updates and rollbacks also fall down when it comes to state
<Irenes[m]>
yeah
<qyliss>
It works well enough because we try to make it work, but there are no _guarantees_
<qyliss>
And without guarantees, well, every update is still a risk even if it's usually okay
<Irenes[m]>
yes
<qyliss>
So what I'd like to explore with compartmentalized servers mostly focuses on state management
<MichaelRaskin>
Well, a PostgreSQL version change can be only as good as PostgreSQL unless you start duplicating datasets…
<Irenes[m]>
so for example, ... yes
<Irenes[m]>
same example lol
<Irenes[m]>
not by coincidence, databases are hard
<qyliss>
Right, but in a better system than NixOS you could express that a postgres rollback is impossible
<Irenes[m]>
absolutely
<qyliss>
NixOS will let you roll back and end up with a broken database
<MichaelRaskin>
Non-starting, more precisely
<qyliss>
So for servers, I'd like to use isolation to strictly control opportunities services have for creating persistent state
<qyliss>
And then using that, come up with a way of expressing automated state transitions
<qyliss>
Constraints, and so on.
<Irenes[m]>
right, yeah
<qyliss>
Essentially, database migrations, but for a generic individual state unit.
<qyliss>
I have a bunch of ideas that are sort of too vague for words about specific things you can do here
<Irenes[m]>
sure
<qyliss>
But then also, all of these state containers can very easily be backed up, etc. Because they're discreet units.
<Irenes[m]>
right that would be great
<Irenes[m]>
I wish that nixops were in a better state
<Irenes[m]>
it uh... relies on too much of its own state, for my tastes
<qyliss>
Nixops is a product of NixOS, which is itself not great for this, no matter how it tries to position itself.
<Irenes[m]>
yeah
<Irenes[m]>
one thing that I think would be very useful is a tool that diffs two configuration
<Irenes[m]>
s
<Irenes[m]>
like
<Irenes[m]>
diffs the effect of evaluating them
<MichaelRaskin>
Like nix-diff but also with interpretation?
<Irenes[m]>
I admit I haven't studied nix-diff, does it evaluate before it diffs?
<qyliss>
Something nice about the Spectrum Server Edition™ model is that you can easily test state migrations on live data
<qyliss>
Irenes[m]: yes
<MichaelRaskin>
You might need to feed it both instantiations
<Irenes[m]>
okay, good. then what I'd say is the next step is to have tools that present that cleanly and support workflows where you check that before you rebuild
<MichaelRaskin>
Well, easily if you can efficiently create writeable snapshots
<Irenes[m]>
or also tools that check that at the time you commit, if you use version control for your configuration
<qyliss>
Copy the state conatiner, run the migration in an isolated unit with no network/disk/etc access, run the inverse migration, check you get back to what you started with.
<MichaelRaskin>
stdenv rebuilds might drown you in niose
<qyliss>
That gives you a lot of confidence about upgrades and rollbacks.
<Irenes[m]>
I will say that Google uses something like this internally, not wrt Nix but wrt their own configuration language
<Irenes[m]>
and I have seen first-hand that it is useful
<Irenes[m]>
qyliss: hmm... you'd need to support pluggable mechanisms for copying state containers
<qyliss>
yeah
<Irenes[m]>
you can always copy at the filesystem layer if you are okay with stopping the service
<Irenes[m]>
but for databases you want online backups
<qyliss>
I expect that to be solvable
<Irenes[m]>
yeah, me too
<MichaelRaskin>
qyliss: of course this requires bit-perfect migrations
<qyliss>
For all of this, the thing that really jumps out at me is that NixOS is not the foundation to be building on
<Irenes[m]>
interesting
<qyliss>
MichaelRaskin: you could define your own equality function, potentially.
<qyliss>
Because NixOS's model doesn't consider state management within scope at all
<MichaelRaskin>
True, and then you also need to somehow verify that the migrated instance serves good data and not just works
<qyliss>
And so any attempt to do state management on top of it isn't oging to work very well.
<Irenes[m]>
what would you change?
<qyliss>
I would make state management first class, as I have described
<MichaelRaskin>
Well, NixOS module system is a beautiful modelling of shared mutable state on top of a purely functional programming language
<Irenes[m]>
do you think the Nix expression language needs changes, or just the way services are defined?
<qyliss>
Irenes[m]: the language could benefit from being changed but it doesn't have to be
<MichaelRaskin>
This alone makes it a bit wonky for trying to isolate services
<qyliss>
The NixOS module system should go
<Irenes[m]>
hmm okay
<qyliss>
And services should be defined as things you create instances of, rather than singletons
<Irenes[m]>
hm, right
<MichaelRaskin>
Indeed, that's what I do in my system
<qyliss>
Isolation should be opt-out
<Irenes[m]>
that seems exciting
<qyliss>
Yeah
<qyliss>
It's years off, and too early for me to give concrete answers to lots of reasonable questions
<qyliss>
But it's part of the vision
<MichaelRaskin>
Never got to have enough services to actually care about isolating them
<qyliss>
Ten years from now, I want to have solved computers :P
<Irenes[m]>
I would love to be part of this, at some point
<Irenes[m]>
I am ridiculously overcommitted this year but I think as a ten-year vision that's really cool
<qyliss>
Yeah, it's exciting how lots of people have visions that align on this.
<MichaelRaskin>
qyliss: I believe that relative to what I have now, I will only get from your solution minor improvements and valuable hardening
<Irenes[m]>
sometimes the important thing is to be a figurehead and then people will rally to you. you seem to have done that :)
<MichaelRaskin>
Because the real problems with modern computers … are different
<qyliss>
maybe we have different problems, and that's okay :)
<qyliss>
but you're also coming from a much better starting point than the rest of us
<Irenes[m]>
MichaelRaskin: what are your own biggest pain points?
<qyliss>
edef and I have spoken a lot about our visions, and she's working on things at her company starting from a completely different entrypoint, but heading in a very compatible direction
<MichaelRaskin>
It's ecosystem problem
<MichaelRaskin>
People put stuff in horrible formats overfilled with garbage for no reason
<qyliss>
At some point, I'd like to have enough clout to evangelize something like 12factor did for Heroku
<MichaelRaskin>
The reason we have too little actually good software is that most software is not defined in terms of processing information in a useful way
<qyliss>
"Here's a vision of how computers to work. We can get there gradually, so it's feasible. Here's how you should right programs that fit well into this new world, but that you also get benefits from right now."
<MichaelRaskin>
It is defined in terms of being mostly compatible with the garbage on the other end
<MichaelRaskin>
HTML4 Web was hands-down better at everything expressible as text + a few static images.
<MichaelRaskin>
Then an application deployment platform happenned and damaged the actual web of documents containing information a lot.
<MichaelRaskin>
Office formats… well, word processors are just an abomination.
<MichaelRaskin>
Then we have hardware that is a) garbage b) lying garbage.
<qyliss>
I don't think I can help with providing those applications, but I just might be able to provide a system where better applications are the natural thing to write
<MichaelRaskin>
Anything that touches any office format will consist of horrors.
<MichaelRaskin>
Wrapping LibreOffice into proper state management will remove the risk of hard-to-debug unreproducible mysterious behaviours (that I already have on my system), but still it is sometihng that handles office formats, its definition includes mysterious behaviours
<MichaelRaskin>
I definitely like that most of my browsers cannot even find out _if_ there is a sound card, but they are still web browsers.
<qyliss>
In regards to expression integrity and stuff, that's an area I believe edef is looking into, and so I won't be for at least a while to avoid duplicating work, because I trust her judgement there.
<MichaelRaskin>
(well, a lot of stuff I read from tolerable-and-better websites I read in Vim, that's better)
<colemickens>
what does expression integrity even mean? :/ (feeling out of my depth here :P)
<qyliss>
Does your Nixpkgs have a backdoor?
<MichaelRaskin>
That you build LibreOffice with the exact set of vulnerable dependencies intended by the corresponding Nixpkgs maintainers, not with something even more backdoored
<qyliss>
There's also stuff like trusting binary caches, etc.
<MichaelRaskin>
You could also ask about bootstrap tools provenance
<qyliss>
Indeed!
<qyliss>
We've recently spent quite a lot of time talking about that.
cole-h has quit [Quit: Goodbye]
cole-h has joined #spectrum
* edef
waves at Irenes[m]
<edef>
< Irenes[m]> you can always copy at the filesystem layer if you are okay with stopping the service
<edef>
Irenes[m]: this is fine on ZFS, and plausibly btrfs (but i will not touch btrfs myself)
<edef>
Irenes[m]: and i suppose also bcachefs probably, and presumably HAMMER
<edef>
Irenes[m]: ie all *modern* filesystems support ~free, O(1) CoW snapshotting
<Irenes[m]>
oh hi edef!
<Irenes[m]>
oh yeah that makes sense, I didn't even think about copy-on-write
<Irenes[m]>
does it do that atomically for an entire directory?
<Irenes[m]>
apologies for going afk there, I had a call
<edef>
atomically for an entire filesystem
<edef>
and filesystems are things you can have numerous ones of
<Irenes[m]>
ooh, okay
<Irenes[m]>
right, so I could create one for /var/lib/db or whatever
<Irenes[m]>
good to know
<Irenes[m]>
I admit I haven't kept up on the latest copy-on-write stuff because it's at odds with secure deletion
<Irenes[m]>
I think that's just one of those things about focusing on the problems that feel closer to home
<edef>
secure deletion is perfectly possible
<edef>
in fact, it is *more* possible on CoW systems
<Irenes[m]>
I know. it just isn't achievable in practice right now, it needs more vertical integration.
<Irenes[m]>
let me find a paper I recently read
<edef>
i'm currently cooking but it's very straightforward
<edef>
if you choose a cipher that has cheap key setup (for example, ChaCha20), there is no reason *not* to pick a fresh key per CoW block
<Irenes[m]>
I know it's achievable in principle. I would not call it straightforward, because SSDs introduced a whole new set of requirements.
<Irenes[m]>
I mean yeah but you're keeping that key somewhere, too
<edef>
my threat model assumes the disk is malicious
<edef>
Irenes[m]: you can store the key in the block pointer, all the way up to the uberblock
<Irenes[m]>
I approve
<edef>
Irenes[m]: only the *uberblock* key needs to be securely erasable
<Irenes[m]>
that makes sense, yes.
<edef>
so you have 512 bits (you want to keep two key slots) of securely erasable storage *somewhere*
<edef>
and through that you can have forward-secure encryption of arbitrary amounts of data
<Irenes[m]>
does that also help with metadata erasure, ie. evidence that there used to be a file?
<edef>
not any more or less than usual
<Irenes[m]>
sure
<edef>
i don't really understand how one can or would effectively hide that from a malicious disk
<edef>
like, my assumption is that your disk is hosted off a magic NSA-provided SAN over iSCSI or w/e
<Irenes[m]>
I guess that's not my assumption
<Irenes[m]>
I am happy to listen to arguments that it should be
<edef>
i'm not sure what reduced threat model to work with
<edef>
and metadata becomes less legible on a CoW filesystem by nature
<Irenes[m]>
I will need to chew on that and get back to you in a day or so
<Irenes[m]>
I hadn't considered a model so strong, before
<MichaelRaskin>
edef: well, if you are willing to tolerate constant full-rate writes, you can hide file existence from disk
<edef>
right, sure
<MichaelRaskin>
(or if you only access the file one block at a time)
<edef>
i've put some thought into how minimal you can make storage APIs
<edef>
ironically my SSD dying might have eaten my design notes
<MichaelRaskin>
The only copy of your design notes??
<edef>
i was redesigning how backup systems should work!
<Irenes[m]>
aw!
<edef>
regretfully i had not implemented my designs yet
<Irenes[m]>
I would love to comment on your design docs if you ever revisit that topic
<Irenes[m]>
I care about it a lot as well
<edef>
i have discussed some of my storage ideas with a googler and been told i had at least just reinvented colossus
<Irenes[m]>
haha
<edef>
which is probably a sign i should read the colossus paper
<Irenes[m]>
yeah I took the time to understand Colossus while I was at Google
<Irenes[m]>
I figured I should learn as much as I could while there
<Irenes[m]>
I never worked in anything touching on that though