< aj>
sipa: re: #20005 would just adding an autoconf snippet and failing before even trying to build if the bug is present be simpler than trying to get a reliable workaround?
< sipa>
aj: unfortunately i fear that that may mean that people either stop building their own bitcoind, or get accustomed to a --ignore-compiler-bugs flag
< sipa>
because a large number of current distributions ship a broken gcc
< aj>
sipa: debian stable's gcc is 8.3 which is too old i think?? have fedora/rhel/ubuntu not done emergency patches?
< sipa>
aj: there are _no_ GCC releases with the fix
< aj>
sipa: the bug's only in gcc 9 and 10, isn't it?
< sipa>
yes
< sipa>
but all most recent 9.x and 10.x are vulnerable
< sipa>
wumpus: i've disabled the appveyor webhook; it's useless currently
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #20067: refactor: remove use of boost::algorithm::replace_first (master...20201003-get-rid-of-boost-replace_first) https://github.com/bitcoin/bitcoin/pull/20067
< bitcoin-git>
[bitcoin] MarcoFalke reopened pull request #20067: refactor: remove use of boost::algorithm::replace_first (master...20201003-get-rid-of-boost-replace_first) https://github.com/bitcoin/bitcoin/pull/20067
< wumpus>
sipa: thanks!
< wumpus>
sipa: that's great, didn't know it could be done without a change to the repository
< sipa>
wumpus: i hope it works
< wumpus>
I'm honestly not sure anymore whether we should do anything at all, in regard to the gcc bug
< sipa>
wumpus: agree... it's a lot less scary than we first thought, though the concern about introducing new something that is affected by it remains
< wumpus>
testing has shown it doesn't affect our consensus code, that was a potential reason to panic
< sipa>
it doesn't affect anything, actually
< wumpus>
right
< sipa>
(in the 0.20.1 codebase)
< wumpus>
we probably should keep paying attention, or even have an automated test for code that is affected, but it's not enough reason to refuse to build outright or such I mean
< sipa>
agree, i think refusing to build is too big a stick
< wumpus>
(I initially wanted that, but it seems to be much less bad than initially thought)
< aj>
(i dunno, if distros haven't patched already, someone needs to get a bigger stick...)
< wumpus>
they definitely won't patch because of anything we do
< wumpus>
I mwan, for example, last time I tried to get a miniupnp remote code exploit fixed in ubuntu it took a direct example of an exploit to get them to fix it quickly... "it doesn't build bitcoin anymore" is not likely to convince anyone
< wumpus>
I wish someone found an example of the bug actually causing an exploitable security somewhere (and published it ofc)
< luke-jr>
wumpus: it seems very unlikely
< luke-jr>
wumpus: roconnor rebuilt his entire system and nothing stood out like that iirc
< wumpus>
luke-jr: yes I think too that it's unlikely (but also unlikely roconner had every possible remote service installed :-) )
< luke-jr>
heh
< aj>
doesn't seem like anyone's filed a bug for rhel/fedora, debian or ubuntu
< wumpus>
that's very much worth doing if not
< luke-jr>
lol
< luke-jr>
I don't see one on Gentoo's either
< luke-jr>
could they be security-hidden?
< aj>
seems unlikely given the gcc bug's been public for months?
< wumpus>
it's almost like we're the only ones worrying about this, or yeah, that the bugs are hidden, but that would most probably mean someone did find a serious exploit making use of it
< wumpus>
it's sometimes hard to distinguish "no one cares" from "everyone is panicking in secret"
< wumpus>
... though you'd kind of expect swifter action in that case
< sipa>
i don't have the impression anyone is panicking in secret
< roconnor>
Someone contacted me and is attempting to rebuild "all of" the packages in Nix with the gcc bug detection patch.
< luke-jr>
sipa: it doesn't even come close to cleanly applying to GCC 9 - I couldn't rebase it without doubt
< sipa>
luke-jr: oh, i'm misinformed then
< sipa>
roconnor: nice
< luke-jr>
sipa: my solution was to neuter the builtin memcmp entirely
< wumpus>
roconnor: now that's an interesting experiment
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20089: validation: Increase robustness when loading malformed mempool.dat files (LoadMempool) (master...load-mempool-robustness) https://github.com/bitcoin/bitcoin/pull/20089
< aj>
sipa: doesn't InsecureRandBits(n) give a value in [ 0, 1<<(n+1) ) ? or was i talking max, while you were talking average?
< sipa>
aj: no, in range [0...(1<<n)-1]
< bitcoin-git>
[bitcoin] amitiuttarwar opened pull request #20090: [doc] Tiny followups to new getpeerinfo connection type field (master...2020-09-getpeerinfo-conn-type-release-notes) https://github.com/bitcoin/bitcoin/pull/20090
< aj>
sipa: oh, i can't add up! neat!
< sipa>
(InsecureRandBits(n) >> n) should always be 0
< aj>
sipa: my stumbling block was not realising 1<<n wasn't n for n in 0,1,2 i think
< sipa>
ah
< sipa>
exponents are hard
< roconnor>
sipa: I didn't get any memcmp warning when compiling 875e1ccc9fe01e026e564dfd39a64d9a4b332a89.
< sipa>
roconnor: awesome, thank you
< sipa>
aj: a much longer term solution to the "time going backwards" thing... we really shouldn't using a system clock for these things
< sipa>
all of the GetTime*() functions deal with the same clock currently, but there are two distinct use cases for them, and C++(11) conveniently has a clock for each
< sipa>
most clock uses (except those used in block or wallet transaction timestamps) should really be using std::chrono::steady_clock, which can't be converted to real-world clock values, but is sufficient for "X time in the future" decisions
< sipa>
and the other ones should be using std::chrono::system_clock
< aj>
sipa: yeah. i tried switching a bunch of net.h to time_point's once, but got stymied by it not working with atomic.
< sipa>
oh it doesn't
< sipa>
that's annoying
< aj>
sipa: might be fixed with c++14 or 17, i don't remember the details
< aj>
sipa: it was something that needed a noexcept but didn't have one or something
< aj>
sipa: i believe my thought was that we could have a mockable_clock, and then have typechecking for which times were mockable and which ones weren't
< sipa>
aj: i think we should have no non-mockable times :)
< aj>
sipa: hmm, i think the select() delays are better off non-mockable
< sipa>
aj: hmm, right
< sipa>
those should be rare though,i think
< aj>
sipa: yeah, hopefully
< sipa>
i guess we'd want 3 clocks:
< sipa>
* nonmockable, a steady clock for select() & co
< sipa>
* adjusted, a system clock with network-data based corrections
< sipa>
* timings, a steady but mockable clock
< sipa>
do we need a system clock that's non-adjusted anywhere?
< aj>
when we have mocked time, the logs include the system time without adjusting it?
< sipa>
it logs both
< sipa>
[$real_time] (mocked: $mocked_time) ...
< aj>
right, non-adjusted system time and mocktime
< aj>
is adjusted system time okay there?
< sipa>
ah, i see
< sipa>
right, logs may wan5 to report real real non-adjusted system time... but those are also not things stored in variables or so
< aj>
yep
< sipa>
also creating an atomic_time_point should be easy
< sipa>
just store an atomic duration, and convert from_to time_point at store/load time