< bitcoin-git>
[bitcoin] sipa opened pull request #20855: Revert "Add patch to make codesign_allocate compatible with Apple's" (master...202101_revert_codesign_allocate_hack) https://github.com/bitcoin/bitcoin/pull/20855
< jonasschnelli>
0.20.2rc1 macOS signatures are invalid (local test)
< * sipa>
erupts in an apple-demon dispelling chant
< sipa>
pom pom pom pom pom
< jonasschnelli>
0.20.2rc2 attaching the signature with codesign_allocate WITH sipas patch works
< jonasschnelli>
so apple has not fixed it...
< jonasschnelli>
trying now with a signatue done on macOS 10.12
< jonasschnelli>
wild thought: what if we instead of detaching and attaching the macOS sig, we stuff the complete signed binary through the "signer" gitian step and just verify nothing else expect the signature has changed? lame?
< sipa>
that requires a way to remove the signature, and get back to the original unsigned binary
< sipa>
i don't know if there is a reliable way of doing so, and if there is... it still needs codesign_allocate
< jonasschnelli>
sipa: something like hashing the binary "up to the signature"?
< sipa>
yes, but it hashes the binary _after_ running codesign_allocate
< sipa>
which modifies loading instructions in the binary... not something you can easily ignore
< jonasschnelli>
sipa: my idea was to just use pagestuff to get the signature position, then hash the signed binary (without the signature) and hash the unsigned binary and compare
< jonasschnelli>
sipa: yes.. I think that won't work
< sipa>
that won't work
< sipa>
you need to hash the unsigned binary _after_ codesign_allocate
< jonasschnelli>
bah
< sipa>
which gets us back to square one, because the whole problem is recreating the same codesign_allocate step at attaching time
< jonasschnelli>
jup
< jonasschnelli>
testing 0.20.2rc1 now with achow101's signer
< jonasschnelli>
works
< jonasschnelli>
I'm just going to push that signature
< jonasschnelli>
current state: 0.19.2rc1 and 0.20.2rc1 are signed (with achow101's tool), 0.21.0rc4 can't be signed deterministically (needs revert of sipas patch)
< jonasschnelli>
achow101: I think compiling codesign_allocate for macOS should be easy, I just compiled out depends package native_cctools locally on my mac (https://github.com/tpoechtrager/cctools-port/)
< jonasschnelli>
I think we just need to crosscompile that package as well and extract the codesign_allocate and place it in the tarball (and modify the detach-sig-create script to make use of it [as well as required the signapple changes])
< jonasschnelli>
probably name it x86_64-apple-darwin11-codesign_allocate
< sipa>
yeah, i think that's pretty much it
< achow101>
I haven't figured out how to cross compile cctools
< achow101>
but that may be because my knowledge of build systems is slightly lacking
< achow101>
I tried it and got a linux binary out ...
< sipa>
i think you can summon some knowledge about cross compilation here
< sipa>
let me try
< sipa>
*dongcarl*
< achow101>
codesign_allocate can remove a signature, but it doesn't reduce the vmsize so it's unhelpful
< jonasschnelli>
since only the macOS signer needs the codesign_allocate, we could also place a quick build script into the tarball (fetch the cctools/libtapi, compile)
< jonasschnelli>
(might be the cleaner solution and doesn't delay the dependency build)
< aj>
sipa: (a cross compiler you say? that's what you get when you have too many syntax errors right?)
< achow101>
I wonder if there's some way to add a detached sig to the OS detached sigs db at install time
< achow101>
then we wouldn't have to attach the sig to the binary, just make the installer thing put the sig in the right place on the os for us
< achow101>
too bad a dmg isn't actually an installer
< jonasschnelli>
achow101: that would require a custom script (installer) which would require a codesignature as well.
< jonasschnelli>
achow101: do you see any downsides in just using your tool?
< achow101>
The downside is that I have to maintain it lol
< jonasschnelli>
achow101: good point. :)
< sipa>
it's not like apple ever changes anything about their codesignijg infrastructure, right? ;)
< jonasschnelli>
well...
< jonasschnelli>
is Apples codesign using apples /usr/bin/codesign_allocate or does it handle the allocation internally?
< sipa>
jonasschnelli: does it matter?
< sipa>
the documentation says it can use an alternative allocate binary, but it has to be signed by apple
< jonasschnelli>
sipa: maybe we can "patch" (tell it) it to use the self compiled cctools codesign_allocate
< sipa>
if their whole codesigning infrastructure is worth anything, that should be impossible ;)
< sipa>
jonasschnelli: have you already published a signature somewhere created using signapple?
< sipa>
jonasschnelli: that means we no longer need to worry about a bug in signapple that leaks your private key
< sipa>
;)
< sipa>
(if it did, it's too late)
< jonasschnelli>
sipa: go. Take my 0.00032524 BTC!
< sipa>
i mean the codesigning private key
< jonasschnelli>
oh.. well.. that is worth nothing. :)
< sipa>
oh!
< sipa>
well if you could just publish it, that'd save us a lot of trouble
< jonasschnelli>
why?
< jonasschnelli>
people would still need to sign
< sipa>
could be integrated into gitian
< sipa>
in a single phase, even
< jonasschnelli>
hmm... we could share it among gitian signers.
< sipa>
tiny downside... anyone could sign binaries pretending to be bitcoin core
< jonasschnelli>
sipa: the thing is, no-one does verify the signature's origin
< sipa>
what do you mean?
< jonasschnelli>
the private key is property of "Bitcoin Core Code Signing Association" (this is no joke).
< jonasschnelli>
Users just care about a valid signature. Anyone can register at apple, get a valid signing key and sign a mallicious bitcoin core binary.
< sipa>
it'd get reported, and eventually revoked, i would imagine
< jonasschnelli>
That could be.. yes. But after all keys have been uploaded to the attackes server.
< sipa>
but fair point, we (and users) don't actually care about the identity associated with the key
< sipa>
just that somebody somewhere has a key
< sipa>
and unfortunately, the ability to not lose that key means we can't publish it
< jonasschnelli>
I guess there are other keys floating around in the dark-net (valid signing keys)
< jonasschnelli>
publishing will lead to missues for other things and a potential revoke by apple
< sipa>
yes, that's what i mean
< jonasschnelli>
So the secrecy of the key matters,.. but not the identity
< sipa>
yup
< jonasschnelli>
and... if the signing would happen within gitian... not sure if it would be secure _and_ deterministic
< sipa>
i was being sarcastic
< sipa>
of course we can't sign inside gitian
< jonasschnelli>
got me
< jonasschnelli>
i feel like an Asperger sometimes.
< sipa>
i was trying to prove the point that the key does have value, even if it's not a BTC amount :)
< jonasschnelli>
You did.
< sipa>
sorry, this stuff doesn't come across well in textual form always
< jonasschnelli>
heh.. all good
< wumpus>
heh :)
< aqquadro>
hi, reading the op codes list seems there isn't op codes able to verify signatures on arbitrary payload without concat it to output and inputs. I understand right? Thank you very much
< MarcoFalke>
Probably good to see if the mac signature works
< MarcoFalke>
Has there been a single rc with the mac signature?
< MarcoFalke>
(I don't remember when it started breaking)
< sipa>
it started breaking with rc3 iurc
< sipa>
iirv
< sipa>
iirc
< wumpus>
yes, rc3 is what i remember too
< bitcoin-git>
[bitcoin] PiRK opened pull request #20857: update docstring in feature_csv_activation.py to account for 17921 (master...patch-1) https://github.com/bitcoin/bitcoin/pull/20857
< bitcoin-git>
bitcoin/master 0e51a35 Hennadii Stepanov: refactor: Use Mutex type for some mutexes in CNode class
< bitcoin-git>
bitcoin/master 417f95f MarcoFalke: Merge #19915: p2p, refactor: Use Mutex type for some mutexes in CNode clas...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19915: p2p, refactor: Use Mutex type for some mutexes in CNode class (master...200908-netmx) https://github.com/bitcoin/bitcoin/pull/19915
< jonatack>
vasild: MarcoFalke: how are you testing #20849 and #20852 manually... disconnecting outbound onion peers with rpc disconnectnode works for me in both pulls but also on master
< wumpus>
I think we need to get a rc out to get testing started again
< wumpus>
the only focus right now is the macos signing issue
< wumpus>
they aren't even in master yet, I think it's fine to include those in a later rc
< vasild>
jonatack: wrt https://github.com/bitcoin/bitcoin/pull/20849#issuecomment-754602325 -- I can reproduce the issue and was about to reply to your comment, but I wonder if that can be perceived as a step-by-step guide on how to create an evil node on the network that can circumvent the discouragement mechanism of anybody who connects to it...
< vasild>
wumpus: ok
< wumpus>
I mean the whole point of rcs is that people test them, I'm sure people will find other issues as well
< wumpus>
but it continues getting derailed by macos signing issues
< achow101>
jonasschnelli: you can change the codesign_allocate that codesign uses by setting the CODESIGN_ALLOCATE environment variable. Unfortunately it enforces that the codesign_allocate used is signed by Apple so this is utterly useless
< gleb>
sdaftuar: Let me refresh the reasoning. Why did we bump the version for WTXID if there's a special message anyway?
< sdaftuar>
there was some feedback on the mailing list that introducing a new p2p message, particularly between version and verack, should be accompanied by a version bump
< sdaftuar>
since then, there has been some pushback against the idea, with bip 155 being deployed without a version bump, but then that resulted in some last minute changes before the latest release to avoid causing problems for other software
< sdaftuar>
i'd say that many people here think it's not necessary to bump the version to introduce a new p2p message
< sdaftuar>
but that others in the community may disagree
< gleb>
I don't see a reason to bump the version for Erlay, but of course I can't promise.
< gleb>
I'm not planning to do it for now.
< achow101>
jonasschnelli: can you merge all of the rc5 gitian.sigs prs?
< sdaftuar>
cool, thanks
< jnewbery>
can someone ban taurus228 from the repo? Lots of spam comments
< sipa>
jnewbery: done
< jnewbery>
sipa: thanks!
< jonasschnelli>
achow101: can I merge there? I never did before... lets see
< jnewbery>
It seems like you can't delete the 'review comments' that a spammer leaves, and once they're banned from the repo, you can no longer even update them to '.' :(
< jnewbery>
(you can delete PR comments but not review comments)
< bitcoin-git>
[bitcoin] sipa opened pull request #20861: Implement Bech32m and use it for v1+ segwit addresses (master...202101_bech32m) https://github.com/bitcoin/bitcoin/pull/20861