< 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
< achow101> gitian builders: 0.19.2rc1 sigs pushed
< bitcoin-git> [bitcoin] fanquake closed pull request #20739: [0.19] final rc2 backports (0.19...2012-19rc2) https://github.com/bitcoin/bitcoin/pull/20739
< fanquake> achow101: MISMATCH
< achow101> god damnit
< achow101> where?
< fanquake> macOS 0.19.2rc1
< fanquake> 07672b57e4d8adb438e9dc33a180dd062afb6b260077f9a991645ce7b397dd6b bitcoin-osx-signed.dmg
< fanquake> 3fef8ec626dfdd719ce265c279c25cc92c927aa2f11d4bc93cefd480f085cb5a bitcoin-osx-signed.dmg
< sipa> how dis possible
< sipa> the unsigned step matches?
< achow101> The one that MacOS likes the signature for is the correct one
< achow101> https://github.com/achow101/bitcoin/releases/tag/v0.19.2rc1 has all of my results if you want to dig
< fanquake> just rebuilding
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/bc8ada1c1534...8b6acaca2ff7
< bitcoin-git> bitcoin/master 729e1d1 Sebastian Falbesoner: Add gitian PGP key for theStack
< bitcoin-git> bitcoin/master 8b6acac fanquake: Merge #20848: Add gitian PGP key for theStack
< bitcoin-git> [bitcoin] fanquake merged pull request #20848: Add gitian PGP key for theStack (master...add_gitian_pgp_key_for_theStack) https://github.com/bitcoin/bitcoin/pull/20848
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8b6acaca2ff7...8d6715666d24
< bitcoin-git> bitcoin/master 50a6f8f benthecarman: Add benthecarman to keys.txt
< bitcoin-git> bitcoin/master 8d67156 fanquake: Merge #20846: Add benthecarman to keys.txt
< bitcoin-git> [bitcoin] fanquake merged pull request #20846: Add benthecarman to keys.txt (master...patch-1) https://github.com/bitcoin/bitcoin/pull/20846
< fanquake> achow101: all good after a rebuild. I must have had a bad input sitting around or something. .dmg mounts, app launches fine etc.
< achow101> phew
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/8d6715666d24...ff6adac5f461
< bitcoin-git> bitcoin/master d825a39 Antoine Poinsot: gitian-keys: add darosior's key
< bitcoin-git> bitcoin/master ff6adac fanquake: Merge #20847: gitian-keys: add darosior's key
< bitcoin-git> [bitcoin] fanquake merged pull request #20847: gitian-keys: add darosior's key (master...darosior_gpg_key) https://github.com/bitcoin/bitcoin/pull/20847
< 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> gitian builders: 0.20.2rc1 sigs pushed
< 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
< jonasschnelli> I'll give it a try later
< 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
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/ff6adac5f461...b40254b2327b
< bitcoin-git> bitcoin/master a0eb4c5 Pieter Wuille: Revert "Add patch to make codesign_allocate compatible with Apple's"
< bitcoin-git> bitcoin/master b40254b MarcoFalke: Merge #20855: Revert "Add patch to make codesign_allocate compatible with ...
< bitcoin-git> [bitcoin] MarcoFalke merged 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
< wumpus> should we merge #20850 and tag rc5 asap?
< gribble> https://github.com/bitcoin/bitcoin/issues/20850 | [0.21] final rc5 backports by MarcoFalke · Pull Request #20850 · bitcoin/bitcoin · GitHub
< fanquake> yea
< 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] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b40254b2327b...c37600777eea
< bitcoin-git> bitcoin/master 7ff0535 Amiti Uttarwar: [mempool] Remove error suppression on upgrade
< bitcoin-git> bitcoin/master c376007 MarcoFalke: Merge #20854: [mempool] Remove unnecessary try-block
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20854: [mempool] Remove unnecessary try-block (master...2021-01-load-mempool-cleanup) https://github.com/bitcoin/bitcoin/pull/20854
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c37600777eea...34322b7f5cbd
< bitcoin-git> bitcoin/master e864084 Sawyer Billings: doc: Use https URLs where possible
< bitcoin-git> bitcoin/master 1112035 Ikko Ashimine: doc: fix various typos
< bitcoin-git> bitcoin/master 34322b7 MarcoFalke: Merge #20842: docs: consolidate typo & url fixing
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20842: docs: consolidate typo & url fixing (master...consolidate_typo_fixing) https://github.com/bitcoin/bitcoin/pull/20842
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/34322b7f5cbd...fafd725a7c6c
< bitcoin-git> bitcoin/master ed69213 Zero: build: enable unused member function diagnostic
< bitcoin-git> bitcoin/master 819d03b Zero: refactor: took out unused member functions
< bitcoin-git> bitcoin/master fafd725 MarcoFalke: Merge #19846: build: enable unused member function diagnostic
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fafd725a7c6c...417f95fa453d
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/20849 | net: disconnect peers by address without using a subnet by vasild · Pull Request #20849 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/20852 | net: allow CSubNet of non-IP networks by vasild · Pull Request #20852 · bitcoin/bitcoin · GitHub
< jonatack> e.g. i haven't actually reproduced the issue
< MarcoFalke> the rpc works by node id, no?
< * MarcoFalke> afk
< vasild> I did not test it
< vasild> lets devise something...
< jonatack> i tested it with the address
< jonatack> while watching -netinfo 4
< jonatack> with some added custom logging, and it's not hitting the changed code... afk, look more later
< vasild> "rpc setban", if given something that does not contain "/" will ban/disconnect by address
< jonatack> maybe the functional rpc_setban or p2p_disconnect_ban tests could use a little more coverage
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/e6ad8a6220bf...6e28714da357
< bitcoin-git> bitcoin/0.21 3308718 Pieter Wuille: Revert "Add patch to make codesign_allocate compatible with Apple's"
< bitcoin-git> bitcoin/0.21 6e28714 Wladimir J. van der Laan: Merge #20850: [0.21] final rc5 backports
< bitcoin-git> [bitcoin] laanwj merged pull request #20850: [0.21] final rc5 backports (0.21...2101-21rc5) https://github.com/bitcoin/bitcoin/pull/20850
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.21: https://github.com/bitcoin/bitcoin/compare/6e28714da357...4e7b4ce7eb17
< bitcoin-git> bitcoin/0.21 4e7b4ce Wladimir J. van der Laan: build: Bump RC to rc5
< dongcarl> achow101, sipa: Sorry missed the convo ytd, lmk if I can still be of assistance
< wumpus> MarcoFalke: yes, hebasto tested in #bitcoin-builds: hebasto | signed 0.19.2rc1 tested on Big Sur -- the signature is vaild
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.21: https://github.com/bitcoin/bitcoin/compare/4e7b4ce7eb17...15877d160cb8
< bitcoin-git> bitcoin/0.21 15877d1 Wladimir J. van der Laan: qt: Pre-rc5 translations update
< wumpus> so I guess this means we're ready to tag rc5?
< 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
< luke-jr> >_<
< wumpus> well, there we go...
< jonatack> #20829 targets 0.21.0 and has 3 acks
< gribble> https://github.com/bitcoin/bitcoin/issues/20829 | doc: add -netinfo help by jonatack · Pull Request #20829 · bitcoin/bitcoin · GitHub
< jonatack> too late i guess but as it's a help doc for users
< jonatack> vasild: thanks, sent you a message
< bitcoin-git> [bitcoin] laanwj pushed tag v0.21.0rc5: https://github.com/bitcoin/bitcoin/compare/v0.21.0rc5
< wumpus> ^^
< wumpus> jonatack: will take a look
< wumpus> and also at vasild's PRs
< 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
< jonasschnelli> ok... makes sense
< sdaftuar> gleb: around?
< bitcoin-git> [bitcoin] miketwenty1 opened pull request #20858: adding Michael Tidwell to key fingerprint (master...master) https://github.com/bitcoin/bitcoin/pull/20858
< bitcoin-git> [bitcoin] miketwenty1 closed pull request #20858: adding Michael Tidwell to key fingerprint (master...master) https://github.com/bitcoin/bitcoin/pull/20858
< gleb> sdaftuar: what's up?
< sdaftuar> i was wondering whether the erlay bip was going to include a p2p version bump for any reason
< sdaftuar> i'm including a version bump in my own proposal, and didn't want to conflict...
< bitcoin-git> [bitcoin] miketwenty1 opened pull request #20859: Michael Tidwell key submit (master...master) https://github.com/bitcoin/bitcoin/pull/20859
< 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
< jonasschnelli> achow101: I tested and pushed the rc5 sig: https://github.com/bitcoin-core/bitcoin-detached-sigs/commits/0.21 (your turn)
< 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)
< sipa> jnewbery: yeah, i noticed
< sipa> i'd have collapsed them otherwise
< bitcoin-git> [bitcoin] guggero opened pull request #20860: gitian-keys: add key for guggero (master...guggero-gpg-key) https://github.com/bitcoin/bitcoin/pull/20860
< jonasschnelli> achow101: merged the ones that had a travis pass
< achow101> thanks
< achow101> gitian builders: 0.21.0rc5 sigs pushed
< wumpus> achow101: jonasschnelli: thanks for the quick sigs push
< jonasschnelli> 20148367b46453ed4681ea6b1a50e4e8a354ccf101f9353bf4a07f6ce6d3ff75 bitcoin-osx-signed.dmg
< jonasschnelli> (code signature is valid)
< sipa> \o/
< achow101> jonasschnelli: using which tool?
< jonasschnelli> Yours
< achow101> cool
< jonatack> v nice
< wumpus> 🎉
< 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