< 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>
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
< 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