<siraben>
Has there been an attempt to compile Nix expressions to native/C code?
tgamblin-llnl has joined #nixos-dev
<clever>
siraben: currently, the parser turns a nix file into a tree of Expr* objects, each one contains a function pointer to some native code, and some context on how to run it
<clever>
siraben: due to lazyness, an expr like `import ./foo.nix` will just be a pointer to the native import routine, and a path object, and only if you try to eval that part, will it open the file, parse it, and make more Expr objects
<siraben>
I see
<clever>
there are a bunch of tricky edge cases, where nix could perform better
<clever>
for example, if you have a function like this
<clever>
let f = arg1: f2 (f3 "constant") arg1
<clever>
it will re-run the `f3 "constant"` part, every time f is ran
<clever>
but if you instead do:
<clever>
let foo = f3 "constant"; f = arg1: f2 foo arg1;
<clever>
then it will only run the `f3 "constant"` once, and then remember the result
<clever>
siraben: just knowing edge cases like that, can let you write faster nix expressions
orivej has joined #nixos-dev
jonringer has quit [Ping timeout: 264 seconds]
saschagrunert has joined #nixos-dev
<ashkitten>
wonder if nix could use llvm jit for better optimization...
<eyJhb>
So, I know I have found this before and said it before. But is there an expected behaviour for dockerTools.buildImage, when you use runAsRoot and extraCommands? Because, atm. when extraCommands is specified without runAsRoot (which is a list of commands, not a bool!!), then it will run as UID 1000, but if you specify you want to run some runAsRoot commands, your extra commands will also run as
<tazjin>
ashkitten: not easily, and I don't think it would be the best way of speeding it up
<tazjin>
I'm (slowly) designing an alternative interpreter inspired by GHC's STG, which - if done correctly - opens up for things like parallel evaluation of expression subtrees and so on
tgamblin-llnl has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tom39291 has joined #nixos-dev
Jackneill has quit [Ping timeout: 258 seconds]
Jackneill has joined #nixos-dev
cole-h has quit [Ping timeout: 240 seconds]
orivej has quit [Ping timeout: 276 seconds]
orivej has joined #nixos-dev
srk has quit [Ping timeout: 268 seconds]
puck has joined #nixos-dev
orivej has quit [Quit: No Ping reply in 180 seconds.]
srk has joined #nixos-dev
orivej has joined #nixos-dev
saschagrunert has quit [Remote host closed the connection]
saschagrunert has joined #nixos-dev
mkaito has joined #nixos-dev
tilpner has quit [Remote host closed the connection]
tilpner has joined #nixos-dev
AlwaysLivid has joined #nixos-dev
jonringer has joined #nixos-dev
orivej has quit [Ping timeout: 240 seconds]
tgamblin-llnl has joined #nixos-dev
tgamblin-llnl has quit [Client Quit]
srk has quit [Ping timeout: 268 seconds]
srk has joined #nixos-dev
rajivr has quit [Quit: Connection closed for inactivity]
AlwaysLivid has quit [Remote host closed the connection]
AlwaysLivid has joined #nixos-dev
<energizer>
they seem to not believe in reproducible builds
orivej has joined #nixos-dev
<energizer>
"Reproducible builds help—there is a deterministic outcome for the build and we can thus verify that we got it right—but are harder to achieve due to ephemeral data (such as timestamps) ending up in the release artifact. And safe reproducible builds require verification tools, which in turn must be built verifiably and reproducibly, and so on."
<samueldr>
I think "At that point you already have a trusted binary you can use" totally makes sense in their point of view
<samueldr>
without some kind of "FOAF"(?) network telling you a binary is built reproducibly, it does not have impact for security at large... BUT, for distros, it's a whole other issue
<samueldr>
taviso's thinking as a security researcher, for the individual getting a binary
<samueldr>
we are thinking as people having a goal that requires a reproducible binary
<samueldr>
debian-like folks want this to allow more trusted binary builds from a builder
<samueldr>
(as a dev you can verify the second-party builder built the same binary as you did in your testing)
<samueldr>
well, same here in the end
<samueldr>
(I started writing thinking about arbitrary package uploads, but that's exactly why they work on reproducible builds, so they can ditch arbitrary package uploads AFAIUI)
<energizer>
i guess the idea is from nix's point of view, you can't use CAS nix store unless you have reproducible builds, and that's why nix cares?
<gchristensen>
I think the Nix people who are interested in R.B. agree in R.B. as a mission anyway
<samueldr>
I think my point is: we don't need security to believe it's needed to know it's needed
<samueldr>
and I think I agree that it's way less important for security than some say it is
<samueldr>
but don't let yourself think I don't care about reproducible builds! I do!
<andi->
For use it gives technical benefits while allowing to improve trust in binaries.
<andi->
s/use/us/
<samueldr>
yep, to me, security is the least important part of reproducible builds, I think
<samueldr>
it allows _authenticity_ to be verified, but won't prevent bad code or malicious code to exist by itself
<gchristensen>
speaking of which, iso_minimal is so close! https:/r13y.com
<gchristensen>
eh, fix the URL though. copy-paste is broken again.
<andi->
(trust is a foundation for security, if your binaries are always random you can't reason about them)
<samueldr>
only one slash missing!"
<gchristensen>
this is a cool milestone. I guess the gnome iso would be next?
<andi->
samueldr: yeah, exactly. It is important to understand that we are't solving the trusting source code with RB.
<samueldr>
andi-: exactly, it's not 0% of it, but it's not the most important either I guess?
<samueldr>
and if they have the tools to understand the irreproducible parts when analyzing for security, well more power to them
<andi->
It is trusting the translation step. Ideally we would have two different technologies produce the exact same binaries for this to work. Being able to reproduce something wiht Nix just means we have the same backdoor in our binary seeds. Being able to build the same across many means we have all been owned (less likely?)
<samueldr>
+1
<samueldr>
visual studio compiler support when?
<samueldr>
(for linux)
<gchristensen>
they'd have to have owned eelco back in like 2005 when he built them on fedora I think
<samueldr>
unlikely, sure, but not verified against a totally different seed yet :)
<gchristensen>
surely
* energizer
reflects on trusting trust
<gchristensen>
we can just borrow guix's bootstraping work
<worldofpeace>
gchristensen: hahaha, I wonder how reproducible the gnome iso would be
<gchristensen>
I built a report for the plasma iso once :)
<andi->
50% is good enough, right? Just a coin toss away..
<worldofpeace>
i bet it might be lower than 50%, probably
<gchristensen>
I'd kind of like to change r13y to distribute work to multiple machines, but that is a non-trivial change
<clever>
gchristensen: i think the protocol nix uses for building, can query the narhash of a given output remotely, so you can see if they match and only have to pull 1 copy in the matching case
<siraben>
Guix is soon going to reduce their bootstrap to around 1 KB
<ekleog>
siraben: Does guix-the-binary itself weigh less than 1KB? I'd guess not, and to me this is a significant issue in “fix trusting trust” things, because one not only has to care about the compilers used but also about the whole system running when compiling
<ekleog>
that said it's possible to mitigate by having a small-sized bootstrap and then multiple different build toolchains that can run guix/nix code
<domenkozar[m]>
supersandro2000: don't think it needs a github team
<ekleog>
(ideally by doing things like having said toolchains themselves be built based on compilers that have started self-hosting long ago to minimize the risk of common ancestor attack, like the ocaml compiler for one I know of)
<ekleog>
but then… all these attacks are so much more theoretical than just “a committer pushes a backdoor as a patch to libc” that I'm not sure it makes sense to worry too much about these
<energizer>
i wonder how many backdoors are in the build tree of nixos minimal
<energizer>
0? 5? 10?
<domenkozar[m]>
42?
<ekleog>
what might be nice is something like what cargo-crev does for rust, but expanded to all kinds of code
<ekleog>
but then who would actually do the code review? I know I'm personally not
<gchristensen>
I'm going to assume 0 intentional back-doors
<energizer>
gchristensen: i guess that number comes from a general feeling of how things work in the world, not like, threat modeling?
<gchristensen>
from the position that the developers behind those projects are well intentioned and try to do their best, and if they're compromised then ~every Linux distro has the same back doors, which I find generally unlikely
<ekleog>
One possibility might be an intentional back-door that was introduced, hidden, via multiple patches sent to these projects… but then the fact that these projects don't move that much probably helps for this issue (and TBH I'd guess most would be in the kernel because this is one fast-moving project)
<domenkozar[m]>
for NixOS far more dangerous backdoor would be any kind of a security issue in Hydra
<energizer>
i think i'd want to see answers to "in other large software projects, how many successful backdoors have we found" (certainly nonzero) and "how many attempts have we noticed" [nonzero], and "how close have they gotten" [i'm not in a position to judge that]
<gchristensen>
it would be much easier to sneak a back door in from hydra than by poisoning the actual source being built
<domenkozar[m]>
yeah hydra is actually the worst in that sense since there's no separation of concerns
<gchristensen>
(on in to any build service, the issue is the same)
<domenkozar[m]>
well it's not really
<domenkozar[m]>
if you have build agents that communicate via a protocol that surface area is much smaller
<domenkozar[m]>
(but you'd need to have an audit log of that communication, etc)
<domenkozar[m]>
if you design it well it can be quite hard to inject binaries or source
saschagrunert has quit [Remote host closed the connection]
<andi->
Isn't all communication a protocol of sorts? Some just less strict/well defined? I can't follow that argument.
<domenkozar[m]>
andi-: sure, but if you get SQL access on hydra, you get access to inject binaries quite easily in cache.nixos.org
<andi->
On any build system you are submitting a job and you are expecting some derived result. You can only verify if that result is authentic if you already know the answer or have another source for the "correct answer". Meaning you will need to compile multiple times.
<andi->
Do I really? What am I adding? A drv path to outputh hash mapping that I controlled? SCheduling a job instead of another one?
tgamblin-llnl has joined #nixos-dev
<andi->
I really try to understand that threat model. The signing key isn't exposed to the web user - just to the queue-runner (right?). The SQL DB is just listing drvpaths that must still be built and those that already have been produced.
<andi->
As long as I can't modify drv files on hydras disk that is fine, no?
<domenkozar[m]>
doesn't queue-runner use SQL to communicate work?
<ekleog>
domenkozar[m]: I think the more important question wrt. hydra is how is the private key for signing handled — if it's present on each builder and each builder makes sure it's signing only things it locally built, it should be OK I think
<domenkozar[m]>
it's hydra signing things, afaik
<andi->
domenkozar[m]: the SQL db essentially lists drvpaths that should be produced and those have a flag of done, failed or todo IIRC
<gchristensen>
ekleog: no builder has the signing key
<ekleog>
(though I know nothing of hydra internals so it may not be how it's designed, it's just how I'd be designing it because it's the way to do least authority I think)
<ekleog>
oh :(
<gchristensen>
ekleog: it uses the remote build protocol to build remotely, then signs locally. this is a good thing, you don't really want the signing key on individual machines
<gchristensen>
so it builds, the result comes back, signed, streamed to s3
<ekleog>
Well… I don't know, the only threat model I can see this scheme preventing is one builder falsifying builds that were never sent to it; OTOH it adds the hydra queue handler as another point of failure
<ekleog>
(my guess would be that a compromised builder is already the end of the world for us, but maybe that guess is wrong)
<gchristensen>
it would be a problem but possibly not catastrophic, since it doesn't have signing keys or write access anywhere
<ekleog>
so by not having the signing key on the builders we add the protocol handling as well as the queue to the TCB
<ekleog>
hmm yes I guess it helps recovery from compromise
<ekleog>
Random idea: each builder has its own key, and then we have a “re-signer” that checks signature from the builder and then immediately re-signs — with that scheme it'd probably lower the TCB to be minimal, and allow for compromise recovery
<andi->
each builder has it's SSH host key that hydra verified
<andi->
is that enough?
<gchristensen>
correct
<andi->
and the builder verifies hydra via an SSH key
<ekleog>
(my worries with what sounds like the current scheme is, it implies that hydra code must be correct for the signature not to be ill-applied, while signing on the builder and then re-signing only requires the nix code to be correct)
<ekleog>
but well I guess that's just an idea for hydra v2, sounds like it wouldn't really be doable with the current hydra ^^'
<gchristensen>
not quite, hydra's code here is doing almost nothing: it fetches a the path to a drv from the database and calls build on it, then calls copyclosure to the cache
<andi->
but then you need additional signature verification in the hydra code which could be ill applied?
<gchristensen>
hydra's code is concerned almost entirely with managing the queue and building the right thing at the right time. the rest is up to nix
<ekleog>
andi-: Hmm? no, I'd just have a nix instance on the signing-key-enabled machine, that'd download from the cache, verify with the current nix logic that the NARs are signed with a builder key, and then re-sign (though I just realized I've never checked whether signing can be done by nix itself or if it's inherently an hydra operation)
<andi->
but then you allow every builder to push to the cache?
<ekleog>
yup, but the cache is inherently non-trustable anyway so that's not a big deal, so long as it's not signed by the main signing key
<andi->
ekleog: I haven't seen an issue with the curren scheme. Maybe we should focus on finiding issues in that instead of inventing new schemes for no good reason?
<domenkozar[m]>
I'd design it that builders push to the cache since they are not exposed to the internet and they by design are already a liability of what they build
<ekleog>
well, my fear with the current scheme is it relies at least on SSH communication being secure, and on the communication stack between hydra and the builders to be correct
<gchristensen>
ekleog: again, Nix is doing all the interesting parts there. Hydra is just a thin wrapper.
<ekleog>
(granted, the first part of my sentence is included in the second)
<gchristensen>
hydra doesn't know how to sign paths, Nix does
<domenkozar[m]>
anyway, if you get remote execution on hydra then it's game over for sure :)
<andi->
And so it would be in any of the other builder schemes? If you can mess with builds, regardless on how many times you sign it, the content in the bucket can be ill intended.
<andi->
Following your logic we shouldn't sing anything anywhere and have them detached and generated by something like trustix.
<domenkozar[m]>
andi-: would you agree that having an API to talk to a builder is a smaller attack surface than having direct access to what is signed and uploaded to a cache?
<ekleog>
Ok, I've summed up what I understand of the current scheme as well as my suggested scheme here, does that make sense? http://ekleog.xelpaste.net/5NWb5Y
<gchristensen>
ekleog: no, it isn't quite right. it doens't get copy-closure'd to hydra, hydra copy-closures from the builder
<andi->
domenkozar[m]: attack surface on what end ? You mean hydra could be attacked via the worker protocol?
<domenkozar[m]>
andi-: if someone gets control of hydra machine by finding a security hole in web interface
<ekleog>
Hmm ok I thought “gets copy-closured” was a way to say “I don't know which side of the network initiates the copy-closure” — let's say I wrote “Hydra copy-closures the product of B's build to Hydra” :)
<andi->
domenkozar[m]: then they are an unpriv. user that just has DB access. They can't sign or upload paths.
<gchristensen>
ekleog: it is an important distinction, since it means the builder can't push arbitrary paths, hydra only pulls specific paths
<ekleog>
Right, makes sense, thank you for the clarification :)
<andi->
I've recently done that exercise and implemented the worker protocol.
<andi->
I thought that might be a weakness but it turned out not to be that way
<ekleog>
(updated as http://ekleog.xelpaste.net/x91Vvp ; just realized I had put something in the summary TCB that had not needed to be there)
<domenkozar[m]>
ekleog: if you start trusting the signature on the builders, you might as well skip copying stuff to hydra and avoid that work
<ekleog>
domenkozar[m]: You mean, for the “new scheme idea”? It's also what I initially thought, but then understood that there was also disaster recovery that was important, and having a well-isolated machine which only re-signs builds reduces the risk for the main signing key (though an alternative for that would be hardware security tokens plugged to the builders), as well as asserting that
<ekleog>
builders can only falsify builds they were actually sent
<gchristensen>
the signature is on the narinfo, so it doesn't need to download the whole thing to re-sign the narinfo
<gchristensen>
it can just download the narinfo, verify, sign again, upload
<gchristensen>
or skip that: have the builder upload just the NAR and send the narinfo to the central machine to sign
<ekleog>
Oh cool :) as for “skip that”, the thing I'm trying to avoid is relying on the network (incl. ssh tunnels) / communication protocol implementation being correct for security, so just sending the narinfo to the central machine would lose that property
<domenkozar[m]>
ekleog: yeah right, you'd have to revoke the signing key in case a machine is compromised, that's why I'm using auth tokens in Cachix now to ease that pain
<domenkozar[m]>
but I really think machines are hard to compromise if you do the basics right
<adisbladis>
domenkozar[m]: How does Cachix store it's keys?
<domenkozar[m]>
s/machines/builders/
<domenkozar[m]>
adisbladis: which keys?
<ekleog>
domenkozar[m]: right, in my proposed scheme the builder signing key essentially does what a cachix auth token does I think — the advantage of using builder signing keys being that it removes one layer of authentication code, by just reusing the time-tested nix signature verification code (which must already be in the TCB anyway)
<adisbladis>
domenkozar[m]: If you're using auth tokens where is the signing key stored?
<domenkozar[m]>
it's currently centralized, so you'd get access to them as well if you got remote access to Cachix
<adisbladis>
So software keys on a disk somewhere I take it?
<domenkozar[m]>
I'm not willing to share more than that since it can expose information to an attacker :)
<andi->
Security by obsucrity?
<gchristensen>
scary
<ekleog>
(just noticed I had missed one attack variation by hijacking in both the queue and the builder: here is with the updated “scope of damage” http://ekleog.xelpaste.net/OGKk2q )
<ekleog>
that said yes, machines well-handled overall probably don't need that, but security in depth requires trying to reduce the TCB to a minimum, so it's probably still a good thing to do when enough free time magically appears in someone's schedule (ie. never)
<ekleog>
(IOW, I don't think that idea makes sense to implement until we consider moving off hydra altogether, at which point it'd be cool if the new system was designed with a minimal TCB in mind)
<andi->
It is the same with just signing moved to another machine. Yes we could do physical separation (which is good!) but we could also teach hydra to use a hardware token for signing
<andi->
We could probably also use derived keys that are onyl valid for some time and rotate them afterwards.
<ekleog>
hmm? the core of the idea is mostly to have signing happen without any network communication between “building” and “signing” (or “verifying the signature” and “signing”), not to move main-signing to another machine (which I don't know if it already happens and so wrote “main machine” currently)
<domenkozar[m]>
andi-: it's quite common for people to leak their signing key in CI logs and going through replacing all machine public keys is lots of work and painful
<andi->
Yeah, agreed.
<andi->
But the topic was how keys are stored on disk. Worst case should be that someone is able to sign paths while having access to a box but they shouldn't be able to move that key.
<adisbladis>
This ^
<adisbladis>
Storing keys either in a HSM or some KMS solution largely mitigates this
<gchristensen>
it'd be nice if Nix's signing support were extended to support HSMs
<adisbladis>
gchristensen: Nix used to have openssl support...
<dhess>
gchristensen: speaking of which, you've been using Vault with NixOS, yes?
<gchristensen>
dhess: yea
<dhess>
gchristensen: how's that been? Any issues?
<gchristensen>
adisbladis: yeah but now it uses sodium which I think we can all agree is safer in general :P
<adisbladis>
gchristensen: Though tbh I'd rip signing out of Nix entirely and offload it to an external process
<andi->
we would need a hardware token with ed25519 support. Not sure those exist.
<gchristensen>
dhess: it is great! I love it!
<ekleog>
adisbladis: hmm… what would that gain? AFAIU, nix must be in the TCB anyway
<domenkozar[m]>
andi-: sure, I plan to get there - as the trust builds, so will the measures
<adisbladis>
andi-: Sure they do
<andi->
adisbladis: link?
<andi->
(for below a kidney)
<dhess>
gchristensen: Do you have any nice declarative configuration beyond what the standard NixOS module offers? I was actually thinking of doing that bit via Terraform as it looks like otherwise I'd just have a pile of extraConfig = ... if I use the NixOS module
<dhess>
gchristensen: are you using internal storage or Consul?
<adisbladis>
ekleog: It limits what can happen with key compromise
<gchristensen>
dhess: I made a NixOS module to "declaratively" "config" "it" and it was regret :P
<andi->
they are so expensive they can build a backdoor for each customer ^^
<dhess>
gchristensen: heheh I've been there.
<gchristensen>
dhess: right now, file storage but I want to move to consul
<dhess>
gchristensen: oh really, any particular reason?
<ekleog>
adisbladis: hmm… can you clarify the threat model/impact? I can't see it, sorry :/
<gchristensen>
so I can have a second (and third) node on my laptop and somewhere else :)
<dhess>
oh does the internal storage not do replication to multiple nodes? I got the impression it did
<adisbladis>
ekleog: If you pwn the hydra instance you can't just walk away with the key
<adisbladis>
Because it's not even there in the first place
<adisbladis>
Same as a yubikey vs storing stuff in ~/.ssh
<dhess>
adisbladis: do you use a YubiKey for SSH?
<adisbladis>
dhess: Yes
<dhess>
adisbladis: do you use gpg-agent as your SSH agent?
<adisbladis>
I would never ever use a key stored in a file
<adisbladis>
Yes
<adisbladis>
(though I'm not too happy about gpg-agent, but that's another story)
<adisbladis>
At least the security model is good
<dhess>
adisbladis: do you find that it eventually slows down/locks up, say after a week or so ?
<adisbladis>
Nope, not at all
<dhess>
OK. Mine does. Suddenly my builds get slow and I get angry and then remember that I probably need to restart gpg-agent or even reboot. It's probably a macOS USB issue.
<adisbladis>
andi-: But I wouldn't be too opposed to keep using file based keys and sticking them in a vault instance to separate key material access from regular deployment access
<ekleog>
adisbladis: Right, but that's an argument in favor of HSM, not in favor of the key-handling code being in a process separate from nix, no?
<adisbladis>
If it's the only workable pragmatical solution
<adisbladis>
ekleog: No, that's mostly me dreaming of not having to modify nix to support signing hardware and KMS services
<andi->
adisbladis: I'd love short lived keys that are signed by a master key and we just rotate it every few weeks / days automatically.
<ekleog>
ooooh ok I understand now
<andi->
With an expiry time
<adisbladis>
That could work
<adisbladis>
I also like the idea of a resigner infra (I've toyed with a similar concept for Trustix logs)
<adisbladis>
But in the Trustix scheme the original source would also be traceable
<dhess>
adisbladis: have you tried SSH U2F keys yet?
<adisbladis>
No
<gchristensen>
I have
<gchristensen>
they work great for every machine you use, and not at all with any service I care about (github, aws, equinix)
<dhess>
gchristensen: is it possible to configure it to "cache" a touch so that only the first auth every.. say 15 seconds.. needs a touch?
<dhess>
gchristensen: because otherwise I cannot see using it. I would constantly forget that my build isn't making progress because it's trying to access a git repo via SSH and it's waiting for a touch :)
<dhess>
or god forbid NixOps deployments.
<andi->
I've been using TPM based SSH with requiring a physical touch on the device for about a week now... I don't mind it.
<adisbladis>
dhess: NixOps opens a master connection though
<andi->
If you need multiple session to the same host consider using master + control sockets
<adisbladis>
It wouldn't be so bad
<dhess>
andi-: I did one-touch-per-auth with my YubiKey for awhile. It was madness when doing a NixOps deployment to a moderately-sized network.
<andi->
dhess: glue the notebook to your finger and go grab a coffee ;-)
<andi->
You could sign a key that is valid for a minute or two
<dhess>
adisbladis: correct me if I'm wrong but a) NixOps does not support a bastion host and b) if I have 20 hosts, that's 20 touches per deployment. No?
<andi->
SSH certs are a nice alternative
<gchristensen>
replace your SSH key that nixops uses with a vault-provided signed key
<adisbladis>
dhess: NixOps 2.0 will, and yes, one touch per host (at least)
<dhess>
gchristensen: how does that work with NixOps?
<gchristensen>
ehhhyeah not sure
<andi->
wrapper script!
<adisbladis>
Again, NixOps 2.0 ;)
<adisbladis>
With that you can disable nixops key generation and just use your users key
<dhess>
andi-: I have never seen a CA setup that wasn't wayyyyy more trouble than just using a YubiKey. Do you have a recommendation?
<andi->
This isn't theh usual CA thing
<gchristensen>
vault, baby!
<dhess>
gchristensen: OK I will investigate that. But still, NixOps :)
<gchristensen>
I mean,
<gchristensen>
you can let Vault manage your CA for signing SSH keys
<andi->
dhess: man 1 ssh-kegen /CERTIFICATES
<dhess>
yeah I know. And I will check that out, but I don't see how it solves my NixOps problem
<dhess>
andi-: I mean an SSH CA, of course.
<dhess>
I am quite aware of how it works :)
<andi->
ok
<andi->
I would use a yubikey to sign the actual keys you want to use in nixops
<andi->
Would be interesting if you could actually embed the right force commands
<dhess>
Well I do, but NixOps will sometimes use your key, and sometimes use the root key that it creates during first deployment
<dhess>
At least, that used to be true. And you cannot CA or YubiKey that key. I mean I guess I could import it, but...
<andi->
nixops shouldn't create keys...
<dhess>
Well it does :)
<andi->
must be a bug
<andi->
;-
<adisbladis>
I've made it possible to disable that behaviour in nixops2
<adisbladis>
But the default isn't changed
<adisbladis>
I'm tempted to do so, but....
<adisbladis>
I'm not sure it's within our "breakage budget"
<andi->
Check if one exists in the state file and then use it otherwise do not create new ones?
<adisbladis>
I'm talking about entirely disabling key generation
<dhess>
adisbladis: hmm once you've done that, you can basically toss the .nixops DB right?
<adisbladis>
dhess: For none backend deployments, yes
<dhess>
that would be verrrry nice
<adisbladis>
dhess: The state file is becoming optional
<dhess>
that sounds amazing.
<adisbladis>
And can also be stored externally in something like s3
<dhess>
adisbladis: while you're here and we're talking about NixOps... :)
<adisbladis>
Yeah?
<dhess>
adisbladis: how on earth do I use NixOps as a flake? I don't really understand the nixopsConfiguration.default thing
<dhess>
No separation of physical/logical for starters
<adisbladis>
dhess: I'd say "don't" for now
<dhess>
adisbladis: :( That is what I have concluded independently.
<dhess>
spent a few nights on it, just ran into many dead ends
<dhess>
but ok that's fair :) I don't mean to complain.
<dhess>
andi-: did I see that you're on a Mac now?
<andi->
dhess: now, as in this moment, no
<andi->
I have an aarch64 box that happens to be running MacOS right now.
<andi->
(there are two different nows here)
<dhess>
I did not mean literally "now, as in this moment."
<andi->
then the answer is yes
<dhess>
andi-: you also said you've been doing TPM-based SSH; is that on the Mac?
<andi->
dhess: yeah, the secure enclave thing
<andi->
unfortuantely just the nist EC is supported
<dhess>
So with that little wrapper thing that's on GitHub?
<andi->
dhess: secretive
<dhess>
cool thanks
piegames1 has quit [Quit: WeeChat 2.9]
<dhess>
I had not seen that one, only sekey
<andi->
-> #nix-darwin or #nixos-chat ;-)
<dhess>
sorry
tokudan has quit [Remote host closed the connection]
tokudan has joined #nixos-dev
tokudan has quit [Remote host closed the connection]