<Irenes>
there's a whole chain of trust, so don't think of this in terms of signing some particular build artifact, or even running some specific signing tool
<Irenes>
it's a general problem of producing build artifacts that incorporate signatures
<Irenes>
I want to enable users to be present to oversee the build and do the signing step themselves - for example, by unlocking a hardware token
<Irenes>
that's fundamentally interactive
<Irenes>
there are other ways to do this, fully automated ways, but I think they're mostly useful for large corporations; for *individuals* managing their own artifacts, I think interactive flows are best
<Irenes>
in particular I think most individuals don't have the ability to prepare and maintain a server that they don't have access to :)
<Irenes>
so the question is
<Irenes>
how do I reconcile that interactive step with the nix build process?
<Irenes>
one option that I think is *off* the table is to actually prompt the user to authenticate from inside a build script
<Irenes>
that would break all sorts of things
<Irenes>
the closest thing I can think of is the "please accept the license" thing that used to come up
<Irenes>
but I notice that recent NixOS versions have turned that into a config option
<Irenes>
which makes sense for licenses, but does not make sense for signing
<qyliss>
Irenes: what license accepting thing are you referring to? Do you mean the thing where you have to download some file yourself and nix-store --add it manually?
<Irenes>
is that a thing still? I feel like that stopped being a thing
<Irenes>
wasn't there like a Mozilla license or something?
<Irenes>
to use Firefox instead of Iceweasel?
<Irenes>
I'm vague on it
<qyliss>
not that I've ever seen
<qyliss>
the adding to the store thing is still in use, for when we can't legally redistribute binaries or download them on a user's behalf
<Irenes>
oh, I figured out what I was thinking of (by grepping my config)
<qyliss>
it's not intended to be an interactive check -- it just works that way because there's no alternative
<Irenes>
oraclejdk.accept_license
<Irenes>
hmm
<Irenes>
I see
<Irenes>
so I guess, following that model, what I could do is create a separate command that signs the build artifacts and adds the signed copies to the store
<Irenes>
although
<qyliss>
I think interactive signing would have to be done after the Nix build
<Irenes>
I'm not sure that making it deterministic is consistent with security, I'll have to chew on that
<Irenes>
well
<Irenes>
if it can't be added to the store, that's a limitation on deployment because it means I also can't use nixos-rebuild to make it active
<qyliss>
your only other option would be to have some sort of two stage build, where you build, sign, and then build something else that takes the signed versions as inptus
<Irenes>
check my assumption, if signing is not a deterministic function of the payload and the public key (for example, if it incorporates a random salt to mitigate dictionary attacks, or anything like that), I can't add the products of signing to the store and have it work?
<Irenes>
right, yeah
<Irenes>
I mean, I guess I was imagining a three-stage build
<Irenes>
1. nixos-rebuild -> it errors out and says here's your build products, sign them
<Irenes>
2. invoke my new signing tool
<Irenes>
3. nixos-rebuild again
<qyliss>
yes, that would work
<qyliss>
your signing tool would have to write something that would affect evaluation
<qyliss>
a json file containing signatures, for example
<Irenes>
except non-determinism breaks it, right? because the nix store is content-addressed?
<qyliss>
that could be imported by your nix expression
<Irenes>
hm
<qyliss>
the nix store is not content addressed, but that's also not relevant here
<Irenes>
I see what you mean. I was thinking of using the store as the thing that affects evaluation.
<Irenes>
but it doesn't have to be.
<Irenes>
I guess it's also true that signed blobs are going to be precious in a way that typical build products are not
<Irenes>
so perhaps the store isn't the best way to manage them
<qyliss>
well, you can add them to the store if you want, and they'll end up there anyway as part of the second build, but it doesn't buy you very much
<Irenes>
hm yeah
<Irenes>
okay
<qyliss>
I suppose it means you don't have to worry about storing them anywhere else in the meantime
<Irenes>
okay. I think this general flow makes sense.
<Irenes>
I wonder if there's a better way to communicate from step 1 to step 2
<Irenes>
rather than just telling the user the full filename
<qyliss>
"run the following command and try again" would be the way I'd go for that
<Irenes>
sure
<Irenes>
but I mean, without a huge 50-character hash in the command
<qyliss>
ahh
<qyliss>
I don't think so, because in your build you can only write to the store
<Irenes>
I mean, I could be convinced that that's a feature, but it feels weird
<Irenes>
hm
<Irenes>
yeah
<qyliss>
so you have no way to produce a shorter path
<Irenes>
okay
<qyliss>
or, well
<Irenes>
this makes sense, I think
<qyliss>
there is a way you can avoid it I just thought of, but I don't think it'd be worth it
<qyliss>
which is that you could have your tool evaluate the Nix expression and discover the outPath for itself
<qyliss>
but I don't think that would be a good idea
<Irenes>
lol oh
<Irenes>
yes
<Irenes>
I agree
<Irenes>
that is the opposite of small composable pieces :)
<Irenes>
neat thought though
<Irenes>
okay. thanks for talking this through. some of the compromises are uncomfortable ones, so it was helpful to hear that you see them as necessary also.
Synthetica has quit [Quit: Connection closed for inactivity]
justanotheruser has quit [Ping timeout: 260 seconds]