<LnL>
that module currently signs with every rebuild
<dhess>
yeah ok
<matthewbauer>
the problem with codesigning is if it's reproducible, it's not really verifying anything
<matthewbauer>
we'd have to have some way to allow impurities in nix for it to really buseful
<gchristensen>
(pre-build-hook)
<LnL>
pre-build-hook is too early and important for sandboxing
<gchristensen>
hm?
<matthewbauer>
i guess we could expose some path like /root/.ssh/id_rsa with pre-build-hook have some setup hook sign all of the binaries? might not be too bad of a solution and get this stuff in the binary cache
<matthewbauer>
it's definitely a big problem on macOS with not having these signatures, but maybe with something like that we could get a developer id for the Hydra builders to use
<matthewbauer>
lack of signatures & lack of a free ibtool are the biggest disadvantages we have right now vs. Brew
<matthewbauer>
gchristensen: is that how the secure boot stuff will work? that should probably be a bigger priority, but maybe we can reuse the same key signing
<clever>
if CI signs anything in the "trusted" repo, then exploits like this are a major issue :P
<gchristensen>
no, secure boot is done at bootloader-writing-time
<matthewbauer>
clever: nobody's perfect lol. i'm sure other open source projects do that too though? I could sneak a bad commit to any open source project and there's a chance it winds up in a signed release. we are just more agile
<{^_^}>
Homebrew/legacy-homebrew#10199 (by dhess, 7 years ago, closed): Patching from URLs without checksums is a bad idea
<clever>
matthewbauer: yeah, but usually the PR review system keeps things out
<clever>
leaking a github token lets an attacker bypass that entirely
<matthewbauer>
Oh yeah it’s expose to a builder so that’s a vulnerability
<matthewbauer>
I guess we need an after-build-hook
<clever>
matthewbauer: in the issue i mentioned, its worse, the CI config was publicly visible, including the github token
<dhess>
I would be happy to sign my own packages, it doesn't need to be from the Nixpkgs project.
<gchristensen>
does *every* path need to be signed?
<gchristensen>
how does code signing work ...
<matthewbauer>
gchristensen no just the executable needs to be signed
<gchristensen>
there is another major problem here, which is how do you assert that a build _should_ be signed
<matthewbauer>
dhess: yeah that's a little bit easier, but it's still something I'd like in the binary cache. `brew install gdb && gdb ./my-exe` *just works* but `nix run nixpkgs.gdb -c gdb ./my-exe` doesn't
<matthewbauer>
gchristensen: we could just sign all binaries, but that may be overkill. otherwise some meta like `needsMacSignature` could work
<matthewbauer>
dhess: also it's kind of bad to have to go through the "trust this key" process. Ideally we could get a signature for the Hydra builders accepted by Apple
<gchristensen>
given a machine capable of signing builds allow every user to create signed builds?
<gchristensen>
given a machine capable of signing builds, should Nix allow every user to create signed builds?
<dhess>
matthewbauer: I would argue that only some binaries need to be signed, even.
<dhess>
e.g., aws-vault, because it needs Keychain access.
<dhess>
matthewbauer: oh yeah, like you said :)
<matthewbauer>
gchristensen: yeah it should probably restrict it to private keys that the user has access to. I think some of the NixOps secrets implements this
<dhess>
If you do it selectively and use the user's creds rather than Nixpkgs org-level creds, this could be done relatively straightforwardly in nix-darwin I think.
<dhess>
system.codeSignPackages [ gdb aws-vault]
<dhess>
something like that
<matthewbauer>
dhess: if we wanted to, I think you could even have a whitelist of frameworks that need codesigning. if the binary links to that framework, automatically codesign it. need to look at trace_for_pid as well
<dhess>
yeah great idea
<dhess>
thanks for all the 10.12 work btw!
<matthewbauer>
gchristensen: could hydra build secure boot ISOs by default? I think it hits a similar problem with exposing those keys to anyone with hydra access
<gchristensen>
it definitely does have the same problem
<gchristensen>
(though secure-boot signed bootloaders would not be useful unless we had the ~$1m (just guessing) to become trusted)
<gchristensen>
well so maybe one route is using impure environment variables
<gchristensen>
as a way to present the signing keys as a capability, held by the builder
<matthewbauer>
without signatures I think it just aborts? It seems like a silly distinction when the only difference between "trusted" and "untrusted" is a key press away
<matthewbauer>
^ I'm not actually sure if that's true
johnw has joined #nix-darwin
myskran has quit [Quit: myskran]
<gchristensen>
LnL: did you say there was a problem with ssh-ng and max-silent-time?
<LnL>
hmm, I did?
<gchristensen>
I have a vague memory of it
<LnL>
what is the problem specifically?
<gchristensen>
I don't know
<gchristensen>
I thought you had a problem with ssh-ng and max-silent-time not working
<LnL>
don't remember, and I can't find anything in my history
<gchristensen>
ah okay
<gchristensen>
no worries :)
<LnL>
not everything is passed to the other side so --option max-silent-time on the client might not work
<clever>
there was also issues at one point with hydra not being able to forward that option to the build slaves