<thefloweringash>
Everything I read about adhoc signatures indicates they're just a form of hash of the binary, eg https://apple.stackexchange.com/a/317002. Creating the same binary on two different DTKs would be good supporting evidence that there's no auto-generated machine local key
<thefloweringash>
context is trying to clear up the confusion in #95903
<LnL>
I had a feeling this was getting overblown a bit
<thefloweringash>
I had that feeling with the response to the Catalina changes too :-(
<LnL>
actual signatures would be a major pain and not provide any value other than integrity checking for things built locally
<thefloweringash>
to do it properly would probably require installing the daemon to register a local identity somewhere, and sign on adding to the store, and somehow not break hashes of store paths
<thefloweringash>
if that's coming, that really won't be fun. I don't think we're there yet
<LnL>
not necessarily, but nix (or any other compiler for that matter) just needs access to the identity
<LnL>
with that code signing could be implemented within nix and that doesn't require the daemon
<LnL>
but for arm the main question here is what thing inserts this local signature
<thefloweringash>
like adding a private key within the nixpkgs stdenv?
<thefloweringash>
seems like it's the linker, at least based on the docs and the flags: flags=0x20002(adhoc,linker-signed)
<LnL>
no that's pointless, hence nix itself needs support for codesigning
<LnL>
the build process contains logic to execute sandbox-exec instead of the build instructions directly
<LnL>
similarly it can run codesign on the outputs afterwards
<LnL>
that way the build itself and other things can be shielded from the signing identity
<LnL>
anyway
<LnL>
if it's dyld that handles the required stuff we potentially don't have to do anything, since we don't (and can't) build that ourselves
<LnL>
if it's ld then it's a bit of a bigger problem since updating the cctools-port to have support for all this might be tricky
<LnL>
it's one of those things that's kind of opensource but not really IIRC
<thefloweringash>
I think it's ld. I haven't looked at that side yet.
<thefloweringash>
and anything that uses things install_name_tool will need to create a new signature, according to the docs
<LnL>
right, that makes sense
<thefloweringash>
oh, and strip
<thefloweringash>
if we're signing everything we strip, it might not even matter that we don't sign as part of cctools
<LnL>
running codesign in the build is also an option, as long as that doesn't need an identity
<thefloweringash>
you can explicitly codesign with the identity "-" to make an adhoc signature
<LnL>
does mean security_systemkeychain needs to be added and integrated all the way in the bootstrap chain