< phantomcircuit> fanquake, btw 20720 doesn't fix the issue for me
< fanquake> phantomcircuit: Did you completely clean your repo first? You’ll have to rerun autogen etc
< phantomcircuit> yeah
< phantomcircuit> im going to delete the repo to be sure
< fanquake> Ok. If you are still seeing it can you throw your config.log up somewhere so I can take a look?
< luke-jr> if you have to rerun autogen for anything, that's a bug..
< phantomcircuit> fanquake, https://clbin.com/rellR
< phantomcircuit> i deleted the repo so im pretty sure it's still bugged
< fanquake> phantomcircuit: -fcf-protection is no longer in the hardened flags. So my changes is working as expected.
< fanquake> If your still seeing the same issue, there must be another problematic flag
< fanquake> If your post your build output / errors I’ll have a later this arvo
< phantomcircuit> fanquake, i'll do a bisect this time correctly
< phantomcircuit> fanquake, bisect says 076183b36b76a11438463883ff916f17aef9e001
< phantomcircuit> which i think you already knew, but implies that it's still the same flag
< wumpus> achow101: that's so awesome, congrats!!!
< bitcoin-git> [bitcoin] hebasto closed pull request #20717: ci: Fix COMMIT_RANGE variable value for cloned repos (master...201218-clone) https://github.com/bitcoin/bitcoin/pull/20717
< jonasschnelli> ach
< jonasschnelli> achow101: great work!
< jonasschnelli> Are there any risks (compared to the Apple Tool)? I can test the signature on some older macOS VMs.
< bitcoin-git> [bitcoin] jonatack opened pull request #20729: p2p: standardize on outbound-{full, block}-relay connection type naming (master...outbound-connection-type-naming) https://github.com/bitcoin/bitcoin/pull/20729
< wumpus> i think the main risk is "it doesn't work on some OS", testing is important in any case
< achow101> i suppose there could be risk in having the private key being handled by python code
< achow101> the whole thing currently has to be run on an online computer too for the timestamping part to work
< achow101> although I suppose it could be split into 2 steps; the timestamp doesn't require private key access. however I don't know if MacOS will not like the signing time and the timestamp to be too far apart
< sipa> you just need to know when the timestamp time is going to be, right?
< achow101> i guess so
< sipa> ideally the signer works without private key, so there is no risk of exposing anything secret ,;)
< achow101> hah. I did find a segfault in codesign though... I think it was a null dereference.
< achow101> jonasschnelli: if you would like to try using signapple to sign, it should work with our detached-sig-create.sh script as a drop in replacement for codesign
< achow101> you would only need to change that script to call signapple instead of codesign
< jonasschnelli> achow101: can you post the link again of your tool?
< jonasschnelli> I probably need to test it tomorrow,... getting late here.
< achow101> no rush
< jonasschnelli> ModuleNotFoundError: No module named 'setuptools'
< achow101> how do you not have setuptools?
< jonasschnelli> (while calling pip3 install -e .)
< jonasschnelli> dunno
< jonasschnelli> Requirement already satisfied: setuptools in /usr/local/lib/python3.9/site-packages (50.3.2)
< jonasschnelli> ?
< achow101> ??
< jonasschnelli> its again python mix (brew vs local)
< achow101> I updated the docs to list out the dependencies so you can install them one by one
< achow101> also the tool still uses codesign_allocate but we can use the open source one rather than the mac one
< jonasschnelli> achow101: for your info. I tried to verify a random app,... told me "Exception: Unknown blob entry type 4096"
< achow101> interesting
< achow101> it definitely works for verifying our previous releases
< jonasschnelli> (that app had two binaries in their .app package, ... I specified the binary directly)
< jonasschnelli> Yes. Verifying RC2 works.
< jonasschnelli> Will try to sign rc3 with the tool tomorrow.
< achow101> yeah, that error is because there it is using "alternate CodeDirectory array" which I haven't figured out how to verify yet
< jonasschnelli> Nice work... achow101: you'll get the hacker-badge! at the next coredev.tech
< achow101> a guy sent me some psbts that he said core created but nothing could deserialize. I'm looking at them now and it seems like there are a few places where some random bytes are being put in that just don't belong there
< achow101> any ideas on how that could happen?
< sipa> what kind of bytes?
< sipa> where?
< achow101> in one of the txids in the global tx, about 2/3 of the way through, there's a d0 that does not belong
< achow101> everything before, and everything after, matches an expected txid. and if we ignore the length, everything else would deserialize as expected, until we hit another random byte
< sipa> inside the txid?
< achow101> yep
< sipa> that makes no sense...
< achow101> I'm thinking this is a case of memory corruption
< sipa> i don't see what else could cause corruption _inside_ a txid
< achow101> another has corruption inside a value
< achow101> i've asked him to try using another computer with the same wallets
< bitcoin-git> [bitcoin] benthecarman opened pull request #20731: rpc: Add missing description of vout in getrawtransaction help text (master...fix-getrawtransaction-help-text) https://github.com/bitcoin/bitcoin/pull/20731
< phantomcircuit> fanquake, after investigating more this seems unrelated to the hardening options, rather just clang-7 cant build master at all (for some reason?)
< phantomcircuit> actually CC=clang CXX=clang++ ./configure --with-incompatible-bdb --disable-hardening worked
< phantomcircuit> so it is the hardening, but im not sure which part of it
< phantomcircuit> fanquake, iono removing the fcf-protection line entirely fixes the issue
< phantomcircuit> so maybe the check isnt' working?
< fanquake> I looked at the logs you posted on the PR and that option wasn’t being used.
< phantomcircuit> fanquake, i can build with clang, with that commented out, but not with --enable-fuzz
< fanquake> Ok, but the fuzzing build error is different right?
< phantomcircuit> it's the same error
< phantomcircuit> fanquake, the change you made works on the condition that --enable-fuzz isn't set, the failure is seemingly identical though
< phantomcircuit> so your pr is an improvement, but there's still an issue if that makes sense
< phantomcircuit> it's hard to bisect why without rebasing the original pr out, but there's enough commits since that doing that is not trivial at all
< fanquake> how is "/usr/bin/ld: error: ... <corrupt x86 feature size: 0x8>" the same as "multiple definition of `ConsumeNode(FuzzedDataProvider&)'; test/fuzz/fuzz-addition_overflow.o:/home/bitcoin/bitcoin/src/./test/fuzz/util.h:290: first defined here"
< fanquake> I understand there is still an error. However it is not the same one that is being fixed by my PR
< phantomcircuit> fanquake, i guess im mixing up failures in my head, you're right those are different
< fanquake> No worries. What you're seeing now could be the same as what was reported here: https://github.com/bitcoin/bitcoin/pull/20560#issuecomment-748339644
< phantomcircuit> fanquake, yeah looks like it
< phantomcircuit> fanquake, yeah that was it
< phantomcircuit> fanquake, thanks
< bitcoin-git> [bitcoin] pstratem opened pull request #20733: inline non-member functions with body in fuzzing headers (master...2020-12-20-fuzz-inline) https://github.com/bitcoin/bitcoin/pull/20733