< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d202054675c9...09530b0255ab
< bitcoin-git> bitcoin/master fa272df MarcoFalke: ci: Properly bump to focal for win cross build
< bitcoin-git> bitcoin/master 09530b0 fanquake: Merge #21126: ci: Properly bump to focal for win cross build
< bitcoin-git> [bitcoin] fanquake merged pull request #21126: ci: Properly bump to focal for win cross build (master...2102-ciWin) https://github.com/bitcoin/bitcoin/pull/21126
< bitcoin-git> [bitcoin] mint-young opened pull request #21134: Ecc 0.1.2 (master...ecc-0.1.2) https://github.com/bitcoin/bitcoin/pull/21134
< bitcoin-git> [bitcoin] mint-young closed pull request #21134: Ecc 0.1.2 (master...ecc-0.1.2) https://github.com/bitcoin/bitcoin/pull/21134
< bitcoin-git> [bitcoin] fanquake opened pull request #21135: scripts: check for control flow instrumentation in security-check.py (master...security_check_cf_protection) https://github.com/bitcoin/bitcoin/pull/21135
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21138: ci: Re-run wine tests once if they fail (master...2102-ciWin) https://github.com/bitcoin/bitcoin/pull/21138
< wumpus> what is it with spaces before and after PR/issue titles 🙂
< vasild> the i2p "destination" contains the private key for the .b32.i2p address that is derived from it. So, if somebody has yours they can pretend to be your address.
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21139: doc: Add missing copyright header to util/getuniquepath (master...2102-c) https://github.com/bitcoin/bitcoin/pull/21139
< vasild> I think it is unwise for i2pd to print it in plaintext in i2pd logs
< wumpus> yes, although logs can be assumed to be somewhat sensitive, logging private keys to logs is not a good idea in general
< vasild> yeah, I specifically avoid printing the full i2p destination in bitcoin debug.log: https://github.com/vasild/bitcoin/blob/i2p_sam/src/i2p.cpp#L283-L284
< wumpus> good!
< vasild> sdaftuar: try this: https://bpa.st/LO7A
< vasild> sdaftuar: if the request "DEST GENERATE SIGNATURE_TYPE=EdDSA_SHA512_Ed25519" generates "runtime exception: stoi" inside i2pd, then I guess it has a bug or too old and that signature type is not supported (but still should not cause an exception)
< vasild> from https://geti2p.net/en/docs/api/samv3 "The SIGNATURE_TYPE value may be any name (e.g. ECDSA_SHA256_P256, case insensitive) or number (e.g. 1)"
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #21139: doc: Add missing copyright header to util/getuniquepath (master...2102-c) https://github.com/bitcoin/bitcoin/pull/21139
< vasild> sdaftuar: maybe that old i2pd only supports a number? Would "DEST GENERATE SIGNATURE_TYPE=7" work?
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/09530b0255ab...f61c3a109098
< bitcoin-git> bitcoin/master 059e8cc Kiminuo: Change BOOST_CHECK to BOOST_CHECK_EQUAL to see mismatched values when a ch...
< bitcoin-git> bitcoin/master f61c3a1 MarcoFalke: Merge #21125: test: Change BOOST_CHECK to BOOST_CHECK_EQUAL for paths
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #21125: test: Change BOOST_CHECK to BOOST_CHECK_EQUAL for paths (master...feature/boost-equal) https://github.com/bitcoin/bitcoin/pull/21125
< bitcoin-git> [bitcoin] hebasto opened pull request #21140: script: Drop KVM support in gitian-build.py (master...210210-kvm) https://github.com/bitcoin/bitcoin/pull/21140
< hebasto> jonasschnelli: I'll take care of it, if you don't mind
< jonasschnelli> please. thanks
< jonasschnelli> Gitian Linux build log: 12MB. *sigh*
< hebasto> jonasschnelli: done in https://github.com/bitcoin-core/docs/pull/71
< jonasschnelli> thx
< wumpus> fanquake: https://github.com/bitcoin/bitcoin/pull/21135/files#r573609698 I kind of want to implement this with binary pattern matching now :)
< wumpus> the *log* is 12MB? wow
< wumpus> fanquake: seems easier than i thought, it looks like symbols in .text start with "f3 0f 1e fa"
< fanquake> wumpus: heh
< fanquake> Also the short answer to your Q is no. As when we compile our dummy prog for our test, even when opting out of -fcf-protection, you still end up with endbr64 instructions from libc etc. I’ll elaborate in the PR
< wumpus> fanquake: if only a few specific symbols we could ignore those
< fanquake> I think it was 7. Will have another look
< wumpus> i see, the startup symbols (which come from some .o file) still have the instruction when compiling with -fcf-protection=none
< fanquake> Annoyingly, when you filter the objdump output with --disassemble=<symbol> that only specifies the start point, at <sym>, but it displays all symbols after. Although you could then cut off the output after the first newline.
< wumpus> yea i'm going to try to do this without objdump
< wumpus> the symbol listing part is in pixie, as well as extracting section contents, and i think this doesn't need a full disassembler
< wumpus> i agree it's annoying though, the obvious 'look at the first instruction at the entry point' doesn't work because that one always has a endbr64
< wumpus> the straightforward way would be to count the number of occurences of endbr64, if it's more than some threshold it's adding it for every function, otherwise not, but that does seem brittle
< fanquake> yes, however that is also complicated across all the different binaries. We need to test in the PE bins as well.
< wumpus> the obstacle with using symbols is that we don't currently look at the normal (debug) symbol table at all in pixie, only the dynamic symbol table, which doesn't contain any exported symbols for a binary normally
< wumpus> yes, I'm focusing only on ELF for now
< fanquake> My understanding is that this "should" be supported for macOS too, however (haven't checked thoroughly), my assumption is that our LLVM isn't new enough.
< wumpus> though a general function 'give me text section contents and I'll say yes or no' should work for the other binary formats too
< wumpus> if symbols are involved it gets nastier
< fanquake> Sure. By different binaries I also meant bitcoind, bitcoin-wallet, bitcoin-util etc. As any sort of counting thresholds will be different
< wumpus> I'm not sure about that, if it's the entry (.o) objects those are the same for all binaries
< fanquake> ah right. Just checking that the endbr64 count is > that the entry objects count
< wumpus> "the stuff that executes before main" and is always added by gcc
< wumpus> right
< wumpus> there might be a more subtle way though, still looking
< wumpus> on my system a minimal binary has 6 endbr64 instructions with and 5 endbr64 without fcf
< wumpus> (in the .text section)
< wumpus> bitcoind has 39360 and bitcoin-cli has 2665 (with fcf, will try without now)
< fanquake> If I build a "return 0" c prog on my ubuntu box. With it has 9, without it has 7
< wumpus> okay
< fanquake> Actually, sorry, I see the same as you. 5 & 6.
< fanquake> Wasn't filtering by --section=.text
< wumpus> phew :)
< fanquake> heh
< fanquake> Of the symbols in the text section: _start, __do_global_dtors_aux, frame_dummy, __libc_csu_init, __libc_csu_fini have an endbr64 instruction. deregister_tm_clones & register_tm_clones don't. Then we control <main>
< wumpus> yes-looking at the main symbol might be the obvious thing
< wumpus> we can assume it to be always present, after all, and it beats counting
< wumpus> the only snag is that in that case stripping symbols will break the check (as there will be nothing left to point to main), but we don't do that anyhow for our release binaries
< fanquake> I thought we did?
< wumpus> okay in that case maybe i can come up with a heuristic to find main
< wumpus> you're right.
< wumpus> but before or after the security check?
< fanquake> hmm good call
< fanquake> I think it might be after, as the security & symbols checks are run straight after make
< wumpus> after, it appears: https://github.com/bitcoin/bitcoin/blob/master/contrib/gitian-descriptors/gitian-linux.yml (at least i suppose it's the split-debug step)
< wumpus> so checking main is still on the table
< fanquake> Yep. We make, run sec / sym tests, make install & then strip etc
< fanquake> yes strip is called inside split-debug: "@STRIP@ --enable-deterministic-archives -p -s $2"
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/f61c3a109098...cda914228a56
< bitcoin-git> bitcoin/master faa8afe MarcoFalke: ci: Re-run wine tests once if they fail
< bitcoin-git> bitcoin/master cda9142 fanquake: Merge #21138: ci: Re-run wine tests once if they fail
< bitcoin-git> [bitcoin] fanquake merged pull request #21138: ci: Re-run wine tests once if they fail (master...2102-ciWin) https://github.com/bitcoin/bitcoin/pull/21138
< fanquake> wumpus: nice!
< wumpus> i only test fcf level full and none, i think distinguishing between the levels is possible but much more involved (e.g. in addition to function calls you'd also have to check branches)
< wumpus> but it's enough to protect against accidentally leaving it disabled or compiling with a compiler without fcf support
< fanquake> Yes I think that's fine. I'll drop my ELF change for yours, and then just sort out PE.
< promag> b10c: hi
< wumpus> maybe we can do a similar thing with PE by just parsing the disassembly (e.g. find main) dunno, i don't feel like writing a PE parser right now 😒
< wumpus> or simpler, you said that objdump will return disassembly *from* a certain symbol, so if you check the first instruction from there
< fanquake> Yes. The "from" includes 5-6 lines of prelude, before the actual symbol you want, but we should be able to skip that, find the line with <main>, then check that the one after has the instruction
< wumpus> right !
< bitcoin-git> [bitcoin] maayank opened pull request #21141: Add new format string placeholders for walletnotify (master...walletnotify-blockhash) https://github.com/bitcoin/bitcoin/pull/21141
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/cda914228a56...b3dda0af0ea0
< bitcoin-git> bitcoin/master 7a135d5 Kiminuo: Add EditorConfig file.
< bitcoin-git> bitcoin/master b3dda0a Wladimir J. van der Laan: Merge #21123: code style: Add EditorConfig file
< bitcoin-git> [bitcoin] laanwj merged pull request #21123: code style: Add EditorConfig file (master...feature/editorconfig) https://github.com/bitcoin/bitcoin/pull/21123
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/b3dda0af0ea0...3c514cfe628d
< bitcoin-git> bitcoin/master fa2c521 Daniel Kraft: Deduplicate some block-to-JSON code.
< bitcoin-git> bitcoin/master 3c514cf Wladimir J. van der Laan: Merge #21114: Deduplicate some block-to-JSON code
< bitcoin-git> [bitcoin] laanwj merged pull request #21114: Deduplicate some block-to-JSON code (master...getblock-dedup) https://github.com/bitcoin/bitcoin/pull/21114
< pinheadmz> did 0.9 retro-actively prune unspendable outputs that were already in the UTXO set? Or are we stuck with some early OPRETURNs in there, forever?
< pinheadmz> oh maybe just found my answer in txdb.cpp: CCoinsViewDB::Upgrade() there is a migration
< sipa> indeed
< pinheadmz> that wasn't actually rolled out until 0.15 though to go with the per-tx out update? So some old opreturns hung around in the set for a few versions
< sipa> we had migration code for 0.7 to 0.8 too, but that may not be in the codebase anymore
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21142: fuzz: Add tx_pool fuzz target (master...2102-fuzzPool) https://github.com/bitcoin/bitcoin/pull/21142
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/3c514cfe628d...deb185d2fdcd
< bitcoin-git> bitcoin/master 166266a Hennadii Stepanov: script: Make LXC container size suitable for gitian builds
< bitcoin-git> bitcoin/master deb185d Wladimir J. van der Laan: Merge #21130: script: Make LXC container size suitable for gitian builds
< bitcoin-git> [bitcoin] laanwj merged pull request #21130: script: Make LXC container size suitable for gitian builds (master...210209-lxc) https://github.com/bitcoin/bitcoin/pull/21130
< sdaftuar> vasild: thanks. i tried "DEST GENERATE SIGNATURE_TYPE=EdDSA_SHA512_Ed25519" and got the "runtime exception: stoi" inside i2pd, but "DEST GENERATE SIGNATURE_TYPE=7" indeed seems to work
< sdaftuar> fyi i was able to install the latest release of i2pd on my mac, and the PR adding i2p support seems to run fine there (though i haven't yet connected to other i2p peers yet)
< sdaftuar> ah and i just build i2pd from source, and that works too. sweet!
< jonatack> nice!
< sdaftuar> hah, if i understand the i2pd bug correctly, releases 2.24.0 and later seem to have this fixed, and i was on 2.23.0
< jonatack> we're up to 4 I2P peers now, woot
< phantomcircuit> can i use std::filesystem?
< phantomcircuit> i mean like it works on my system but is that allowed
< sipa> phantomcircuit: i believe it does not work for all our currently supported platforms
< sipa> but look at fs.h, which has an abstraction that closely matches it
< phantomcircuit> yeah im using that now, it's missing the ::exists method which would simply my code a bit
< phantomcircuit> i guess i can just use the boost filesystem stuff directly
< fjahr> #19145 might be ready for merge. It has 4 ACKs by sjors, jonatack, ryanofsky and achow101.
< gribble> https://github.com/bitcoin/bitcoin/issues/19145 | Add hash_type MUHASH for gettxoutsetinfo by fjahr · Pull Request #19145 · bitcoin/bitcoin · GitHub
< Kimi> phantomcircuit, Is this what you are looking for https://github.com/bitcoin/bitcoin/pull/20744?
< phantomcircuit> Kiminuo, yes but also that's a huge change
< phantomcircuit> +96-482 fanquake why not do that kind of pr in smaller pieces?
< sipa> phantomcircuit: i think you can just use fs
< sipa> as it aliases boost::filesystem, which has exist
< phantomcircuit> oh it does
< Kiminuo> phantomcircuit, there are PRs that make the change smaller
< phantomcircuit> sipa, nice
< Kiminuo> but then you hit differences between std::fs and boost::fs (https://github.com/bitcoin/bitcoin/pull/19245)
< Kiminuo> Ah but you are after your own code using std::fs
< phantomcircuit> Kiminuo, yes
< bitcoin-git> [bitcoin] danben opened pull request #21144: test: convert feature_bip_sequence.py to use MiniWallet (master...test-feature-bip68-sequence-without-wallet) https://github.com/bitcoin/bitcoin/pull/21144
< dongcarl> #proposedmeetingtopic Initial Guix Release Transition Plan for 22.0 #21145
< gribble> https://github.com/bitcoin/bitcoin/issues/21145 | Guix Release Transition Plan for 22.0 · Issue #21145 · bitcoin/bitcoin · GitHub
< luke-jr> dongcarl: minimum viable includes gitian descriptors
< luke-jr> otherwise it is a security regression
< luke-jr> I'd help, but I can't get Guix to work, so..
< bitcoin-git> [bitcoin] glozow opened pull request #21146: [WIP] validation/coins: limit MemPoolAccept access to coins cache (master...2021-02-coinsviews) https://github.com/bitcoin/bitcoin/pull/21146
< dongcarl> luke-jr: Would you change your mind if I were to package Guix for Gentoo?