profile
viewpoint
practicalswift practicalswift Independent Bitcoin Core contributor 100% independent. Not for sale. https://twitter.com/practicalswift Donations: 15n9yZyf73X9Ex3RznCPAxSQzCwAVFJeex

apple/swift 53917

The Swift Programming Language

apple/swift-evolution 11549

This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.

apple/swift-package-manager 8007

The Package Manager for the Swift Programming Language

apple/swift-corelibs-foundation 4033

The Foundation Project, providing core utilities, internationalization, and OS independence

apple/swift-corelibs-libdispatch 1894

The libdispatch Project, (a.k.a. Grand Central Dispatch), for concurrency on multicore hardware

ElementsProject/lightning 1747

c-lightning — a Lightning Network implementation in C

apple/swift-corelibs-xctest 862

The XCTest Project, A Swift core library for providing unit test support

apple/swift-llbuild 798

A low-level build system, used by Xcode and the Swift Package Manager

pull request commentbitcoin/bitcoin

test: Fix rpc_net intermittent issue

ACK fa5f46600fb98f1b35346bedc1a66c9019d01114: patch looks correct

Thanks for fixing flaky tests :)

MarcoFalke

comment created time in 8 hours

pull request commentbitcoin/bitcoin

Travis CI system link (https://travis-ci.org/) added for clarity

ACK 1a520fc8dbe32b9f9fd4b38c4b70660a64e26e05: why not :)

sushant-varanasi

comment created time in 8 hours

pull request commentbitcoin/bitcoin

wallet, refactor: Include headers instead of function declarations

ACK 1d5ac6062603e8ed494c8edacbdd314377e83627

hebasto

comment created time in 15 hours

pull request commentbitcoin/bitcoin

net: ensure CNode::m_inbound_onion is inbound, add getter, unit tests

Concept ACK

Thanks for improving testing!

jonatack

comment created time in 15 hours

pull request commentbitcoin/bitcoin

Use -Wswitch for TxoutType where possible

Concept ACK: -Wswitch is good, and termination via assert(false); is better than UB :)

From the standard: "Flowing off the end of a function is equivalent to a return with no value; this results in undefined behavior in a value-returning function." (C++11, [stmt.return])

MarcoFalke

comment created time in 15 hours

push eventpracticalswift/bitcoin

practicalswift

commit sha cfb2e4d9e33dcac8a5a4d72f52971b3fd9080323

Add syscall sandboxing

view details

push time in 19 hours

pull request commentbitcoin/bitcoin

Make Assert(…) usable in all contexts. Make implicit assumptions explicit.

I think adding asserts should be making it clearer for people to see why the code is safe as well as automated tools.

I agree about that statement :)

In addition to that use I also think assertions can be useful to get deterministic termination in case where we otherwise would get a null pointer dereference (if our assumption of non-null turns out to be false).

Why is that desired?

One might think that a null pointer dereference is guaranteed to terminate execution. Unfortunately that is not the case: deterministic termination is the best outcome. Another possible outcome is what in the literature is called "optimization-unsafety" which can be problematic from a security perspective.

There is a neat paper covering optimization-safe code called "Towards Optimization-Safe Systems: Analyzing the Impact of Undefined Behavior" which I recommend for context.

Personally I think adding assertions can be a cheap way to get avoid some instances of potentially "optimization-unsafe code". That is my personal opinion: I know others might not agree and that is fine of course :)

(If you are getting this from an automated tool, are there reports from it around? I remember there were previously somewhere)

IIRC Coverity and Clang's Cross Translation Unit (CTU) static analysis flag these cases. I think most static analysers doing pointer analysis would flags some of these since it is non-trivall for them to infer non-nullptr in these cases AFAICT. I wouldn't be surprised if PVS Studio and cppcheck flags these too as an example.

I don't have any reports readily available, but feel free to check the instructions in #18920 for instructions on how to get Bitcoin Core reports from Clang Static Analysis, clang-tidy and cppcheck. It only takes a couple of minutes of setup :)

Hope that helps! :)

practicalswift

comment created time in 19 hours

pull request commentbitcoin/bitcoin

Show name, format and if uses descriptors in bitcoin-wallet tool

ACK a4b1588c6555b164fdd5e41164bf9358a5194660: patch looks correct :)

jonasschnelli

comment created time in a day

pull request commentbitcoin/bitcoin

build: pkg-config related cleanup

Concept ACK: nice cleanup!

hebasto

comment created time in a day

pull request commentbitcoin/bitcoin

wallet: Make BDB support optional

Concept ACK

achow101

comment created time in a day

pull request commentbitcoin/bitcoin

p2p: improve onion detection in AttemptToEvictConnection()

Concept ACK

jonatack

comment created time in 2 days

pull request commentbitcoin/bitcoin

p2p: improve onion detection in AttemptToEvictConnection

I could refactor ATEC but that doesn't mean people will be eager to review it, …

FWIW I would be very eager to review a change which made AttemptToEvictConnection unit testable. As demonstrated it can be made unit testable with only few lines of code.

I've always been somewhat amazed about how little testing AttemptToEvictConnection has considering the importance of that function for the network. See #16660 (August 2019) and #19966 (September 2020) for context.

jonatack

comment created time in 2 days

pull request commentbitcoin/bitcoin

p2p: improve onion detection in AttemptToEvictConnection

@jonatack

unlikely to be merged (unless someone of v high stature drives it)

I find it very concerning that you're worried that you're not "high stature" enough to suggest such a change.

Either it is in the best interest of our users to have the code merged, or it is not.

Who wrote the code simply doesn't enter that equation.

jonatack

comment created time in 2 days

pull request commentbitcoin/bitcoin

p2p: improve onion detection in AttemptToEvictConnection

Concept ACK, but please add a AttemptToEvictConnection unit test for this scenario.

See #19966 on ideas on how to make AttemptToEvictConnection testable, or feel free to cherry-pick in 818dd2a04da1ae7329c58a79a4fade5ec62c549d and df1328fcecc3f359574fa53979402894b4a73a12 from #19972 ("tests/net: Add fuzzing harness for node eviction logic. Make node eviction logic testable.") .

jonatack

comment created time in 2 days

pull request commentbitcoin/bitcoin

test: Switch to BIP341's suggested scheme for outputs without script

Concept<sub>ACK</sub>

sipa

comment created time in 2 days

pull request commentbitcoin/bitcoin

ci: Enable -Werror for Travis builds, and document exceptions

Concept ACK: deduplication is good

hebasto

comment created time in 2 days

Pull request review commentbitcoin/bitcoin

ci: Enable -Werror for Travis builds, and document exceptions

 if test "x$enable_werror" = "xyes"; then   if test "x$CXXFLAG_WERROR" = "x"; then     AC_MSG_ERROR("enable-werror set but -Werror is not usable")   fi-  AX_CHECK_COMPILE_FLAG([-Werror=gnu],[ERROR_CXXFLAGS="$ERROR_CXXFLAGS -Werror=gnu"],,[[$CXXFLAG_WERROR]])

Heh, thanks! Literally on the same line :) Sorry.

hebasto

comment created time in 2 days

PullRequestReviewEvent

push eventpracticalswift/bitcoin

practicalswift

commit sha 79ef8324d4c85ed16a304e98805724b8a59022ac

tests: Add fuzzing harness for CConnman

view details

push time in 2 days

pull request commentbitcoin/bitcoin

Make Assert(…) usable in all contexts. Make implicit assumptions explicit.

@ajtowns I'm leaving this one as up for grabs now that the first commit is included in #20138 :)

practicalswift

comment created time in 2 days

PR closed bitcoin/bitcoin

Make Assert(…) usable in all contexts. Make implicit assumptions explicit. P2P Utils/log/libs Validation
  • Make Assert(…) (util/check.h) usable in all contexts.
  • Use Assert(…) to make implicit assumptions explicit.

Before the first commit:

./chain.h:404:23: error: C++11 only allows consecutive left square brackets when introducing an attribute
        return (*this)[Assert(pindex)->nHeight] == pindex;
                      ^
+5 -4

1 comment

4 changed files

practicalswift

pr closed time in 2 days

pull request commentbitcoin/bitcoin

validation: Increase robustness when loading malformed mempool.dat files (LoadMempool)

Could someone restart Cirrus please? :)

practicalswift

comment created time in 2 days

PR opened bitcoin/bitcoin

tests: Add fuzzing harness for CConnman

Add fuzzing harness for CConnman.

See doc/fuzzing.md for information on how to fuzz Bitcoin Core. Don't forget to contribute any coverage increasing inputs you find to the Bitcoin Core fuzzing corpus repo.

Happy fuzzing :)

+195 -0

0 comment

3 changed files

pr created time in 2 days

push eventpracticalswift/bitcoin

MarcoFalke

commit sha fa68755364473e48cf039e8cc2d08036fe58c1f6

contrib: Fix gen_key_io_test_vectors.py imports

view details

fanquake

commit sha b3527fd2e9be5a94b84433ae229cdf0aaa2d3e7d

Merge #20168: contrib: Fix gen_key_io_test_vectors.py imports fa68755364473e48cf039e8cc2d08036fe58c1f6 contrib: Fix gen_key_io_test_vectors.py imports (MarcoFalke) Pull request description: The script currently fails with ``` Traceback (most recent call last): File "./gen_key_io_test_vectors.py", line 18, in <module> from segwit_addr import bech32_encode, decode, convertbits, CHARSET ImportError: cannot import name 'decode' from 'segwit_addr' ``` Fix that. Also, unrelated cleanup to use the `bytearray.hex()` method instead of importing a library. https://docs.python.org/3.5/library/stdtypes.html#bytes.hex ACKs for top commit: theStack: tested ACK fa68755364473e48cf039e8cc2d08036fe58c1f6 Tree-SHA512: 45ff7d710de3d0ef5ac6d91543cff0edff6189d2cd00b0f8889f4361e66ef1825f12aea9e71d62038c14a7a531bfc95ffe9a1df83b85aa7f3dd666df07a6be81

view details

practicalswift

commit sha 6a980a49cdbe57086db82754811c48302d7ba6ef

tests: Add fuzzing harness for CConnman

view details

push time in 2 days

create barnchpracticalswift/bitcoin

branch : fuzzers-connman

created branch time in 2 days

Pull request review commentbitcoin/bitcoin

ci: Enable -Werror for Travis builds, and document exceptions

 if test "x$enable_werror" = "xyes"; then   if test "x$CXXFLAG_WERROR" = "x"; then     AC_MSG_ERROR("enable-werror set but -Werror is not usable")   fi-  AX_CHECK_COMPILE_FLAG([-Werror=gnu],[ERROR_CXXFLAGS="$ERROR_CXXFLAGS -Werror=gnu"],,[[$CXXFLAG_WERROR]])

I see -Werror being removed here, but where is it re-added? :)

hebasto

comment created time in 2 days

PullRequestReviewEvent

issue commentbitcoin/bitcoin

Make non-critical unconditional logging conditional to reduce risk of disk fill attacks and to improve user experience

@naumenkogs

Oh, to be clear: I meant "peer triggerable" as the union of a.) "peer triggerable in low volume" (spammy but generally not a problem from a security perspective), b.) "peer triggerable in high volume" (may be used for disk fill attacks).

Note that the first case "peer triggerable in low volume" includes logging of events that is the result of "remote peer (mis)behaviour".

Generally I subscribe to this logging philosophy described by MarcoFalke in #19995: "I'd prefer if unconditional logs were only used for the init/shutdown sequence and local system errors, such as data corruption. Anything else the average user probably doesn't care about, and if they did, they could enable the corresponding debug category and provide enough disk space for the debug log file.", and ideally in combination with some kind of general mitigation like the one I suggested in #19995 ("Mitigate disk filling attacks by temporarily rate limiting LogPrintf(…)").

Which are (a)? Most seem (b) to me, and I'm not even sure they're that "uninteresting" (although the content could be improved to be user-friendly).

I think these are spammy/uninteresting:

src/flatfile.cpp:   LogPrintf("Pre-allocating up to position 0x%x in %s%05u.dat\n", new_size, m_prefix, pos.nFile);
src/validation.cpp: LogPrintf("Leaving block file %i: %s\n", nLastBlockFile, vinfoBlockFile[nLastBlockFile].ToString());

I think these are peer triggerable in the sense that they are the result of "remote peer (mis)behaviour" (and hopefully only in low volume):

src/net.cpp:        LogPrintf("socket send error %s\n", NetworkErrorString(nErr));
src/net.cpp:        LogPrintf("socket sending timeout: %is\n", nTime - pnode->nLastSend);
src/net.cpp:        LogPrintf("socket receive timeout: %is\n", nTime - pnode->nLastRecv);
src/net.cpp:        LogPrintf("ping timeout: %fs\n", 0.000001 * count_microseconds(GetTime<std::chrono::microseconds>() - pnode->m_ping_start.load()));

If someone comes up with a way in which these could be made peer triggerable in high volume then that should be discussed with security@ of course :)

(And if we had a mitigation in place we wouldn't have to worry much at all :))

practicalswift

comment created time in 3 days

pull request commentbitcoin/bitcoin

test: Fix -Wunused-function warnings if configured --without-libs

ACK 76bbcc414f3001b16ac0101f738ed0b3e6f1a372: diff looks correct

hebasto

comment created time in 3 days

issue commentbitcoin/bitcoin

fuzz: ASAN complaint on macOS with -fsanitize=fuzzer,address,undefined

@Crypt-iQ Sorry, I don't have any Mac to test on and I haven't seen this issue under Linux. I'm afraid I'll have to let someone else tackle this issue :)

Crypt-iQ

comment created time in 3 days

issue openedbitcoin/bitcoin

Make non-critical unconditional logging conditional to reduce risk of disk fill attacks and to improve user experience

As MarcoFalke noted in #19995:

I'd prefer if unconditional logs were only used for the init/shutdown sequence and local system errors, such as data corruption. Anything else the average user probably doesn't care about, and if they did, they could enable the corresponding debug category and provide enough disk space for the debug log file.

I agree that we use too much unconditional logging.

It is bad for two reasons:

  • From a security perspective unnecessary unconditional logging risks open up for disk fill attacks.
  • From a usability perspective unnecessary unconditional logging risks burying important log messages (anomalies) in logs about mundane expected stuff (non-anomalies).

I suggest gradually making non-critical unconditional logging conditional to reduce risk of disk fill attacks and to improve user experience.

More concretely that would mean changing from LogPrintf("…\n"); to LogPrint(DEBUG_CATEGORY, "…\n");.

Some candidates for changing from unconditional to conditional debug logging:

src/flatfile.cpp:   LogPrintf("Pre-allocating up to position 0x%x in %s%05u.dat\n", new_size, m_prefix, pos.nFile);
src/net.cpp:        LogPrintf("socket send error %s\n", NetworkErrorString(nErr));
src/net.cpp:        LogPrintf("socket sending timeout: %is\n", nTime - pnode->nLastSend);
src/net.cpp:        LogPrintf("socket receive timeout: %is\n", nTime - pnode->nLastRecv);
src/net.cpp:        LogPrintf("ping timeout: %fs\n", 0.000001 * count_microseconds(GetTime<std::chrono::microseconds>() - pnode->m_ping_start.load()));
src/validation.cpp: LogPrintf("Leaving block file %i: %s\n", nLastBlockFile, vinfoBlockFile[nLastBlockFile].ToString());

These are (AFAICT) either a.) peer triggerable or b.) uninteresting from a user perspective :)

Getting rid of the cases above as a start would significantly reduce the amount of log spam when in steady state (non-IBD).

created time in 5 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha 97a079d0c25908caf615f25570683206cd785a1e

Add GitHub Codespaces integration

view details

push time in 5 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha 77c5c34518ebb7d2e29adaeeefd90d5e89035eec

fixup

view details

push time in 5 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha adf3b755decd85f9558fe2f971b2fb86b7c3ed85

update

view details

push time in 5 days

pull request commentbitcoin/bitcoin

Bump minimum python version to 3.6

ACK modulo CI failure :)

ajtowns

comment created time in 6 days

pull request commentbitcoin/bitcoin

Per-Peer Message Capture

ACK 2418ec658ccd2e8e033bced0f5b7c183946940ac

troygiorshev

comment created time in 6 days

Pull request review commentbitcoin/bitcoin

Per-Peer Message Capture

 uint64_t CConnman::CalculateKeyedNetGroup(const CAddress& ad) const      return GetDeterministicRandomizer(RANDOMIZER_ID_NETGROUP).Write(vchNetGroup.data(), vchNetGroup.size()).Finalize(); }++void CaptureMessage(const CAddress& addr, const std::string& msg_type, const Span<const unsigned char>& data, bool is_incoming)+{+    auto time = GetTime<std::chrono::microseconds>();++    // Windows folder names can not include a colon+    std::string clean_addr = addr.ToString();+    std::replace(clean_addr.begin(), clean_addr.end(), ':', '_');++    fs::path base_path = GetDataDir() / "message_capture" / clean_addr;+    fs::create_directories(base_path);++    fs::path path = base_path / (is_incoming ? "msgs_recv.dat" : "msgs_sent.dat");+    CAutoFile f(fsbridge::fopen(path, "ab"), SER_DISK, CLIENT_VERSION);

If measurements show that this ever becomes a problem in practice it can be tackled in a follow-up.

TBH I'm much more worried about the possible file descriptor DoS vector that we would risk open up if the file descriptor were left open open.

Security first! :)

troygiorshev

comment created time in 6 days

PullRequestReviewEvent

PR opened bitcoin/bitcoin

Taproot follow-up: Make ComputeEntrySchnorr and ComputeEntryECDSA const to clarify contract

Make ComputeEntrySchnorr and ComputeEntryECDSA const to clarify contract.

+2 -2

0 comment

1 changed file

pr created time in 6 days

push eventpracticalswift/bitcoin

practicalswift

commit sha 51365674e828ae95477570019738ab32aa572241

script: Make ComputeEntrySchnorr and ComputeEntryECDSA const to clarify contract

view details

push time in 6 days

create barnchpracticalswift/bitcoin

branch : const-ComputeEntrySchnorr

created branch time in 6 days

pull request commentbitcoin/bitcoin

signet: Fix uninitialized read in validation

re-ACK fa723e3d43e63e8424d97d21d8f2cc8136aba206: patch still looks correct

MarcoFalke

comment created time in 6 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha 0a511b15270710586ac0696f728903c68c9a1284

Add links

view details

push time in 7 days

PR opened dennisreimann/bitcoindevlist.com

Add hyperlinks

Add hyperlinks.

No text added :)

+1 -1

0 comment

1 changed file

pr created time in 7 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha 44347af7ea37ab6f11ed6e28d108178b41d14c70

Add links

view details

push time in 7 days

create barnchpracticalswift/bitcoindevlist.com

branch : practicalswift-links

created branch time in 7 days

pull request commentdennisreimann/bitcoindevlist.com

Add practicalswift

After some squeezing my description is now trimmed to less than two tweets of size, and roughly 2 % smaller than Chris' entry. Acceptable? :)

practicalswift

comment created time in 7 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha d0c69a7287595b9f2602fce6eac70ea19382e9c7

Add practicalswift

view details

push time in 7 days

pull request commentdennisreimann/bitcoindevlist.com

Add practicalswift

@dennisreimann I think Chris' entry is fine (567 bytes): it is roughly the length of two tweets (560 bytes). As a donor I appreciate two tweets of context to be able to curate a short list of donatees without having to click them all :)

I'll trim down my entry so that it significantly smaller than Chris' entry and we should hopefully be ready to go. Will push soonish! :)

practicalswift

comment created time in 7 days

pull request commentbitcoin/bitcoin

signet: Fix uninitialized read in validation

re-ACK fa60f0dc039d2fa5c6d379f20dce964e43c52372: patch still looks correct

MarcoFalke

comment created time in 7 days

pull request commentdennisreimann/bitcoindevlist.com

Add practicalswift

@dennisreimann Thanks a lot for your quick review! I've now tried hard to shorten it while still giving readers the relevant information. I managed to shorten it by removing two sentences. Is it acceptable now? :)

practicalswift

comment created time in 7 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha e4568131711a6345439617d5a5a6334dd689beb4

Add practicalswift

view details

push time in 7 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha 97dfba117cc4d5554a368160a16c08f489bc689d

Add practicalswift

view details

push time in 7 days

pull request commentbitcoin/bitcoin

net: Add regression fuzz harness for CVE-2017-18350. Add FuzzedSocket. Add thin SOCKET wrapper.

@MarcoFalke Thanks for your Concept ACK. Would you mind reviewing the code too? :)

practicalswift

comment created time in 7 days

pull request commentbitcoin/bitcoin

net: Add regression fuzz harness for CVE-2017-18350. Add FuzzedSocket. Add thin SOCKET wrapper.

Friendly review beg :)

Concept NACK:s are totally fine too: that would allow me to move forward with other fuzzing stuff without having to keep this PR updated :)

practicalswift

comment created time in 7 days

pull request commentbitcoin/bitcoin

tests: Update UBSan suppressions file with suppressions needed for clang 12 (current trunk)

Although given it's commented out, it's just the difference of applying your own patches vs un-commenting the lines pre-build?

The reason it is commented out is that older versions of UBSan errors on suppressions it cannot parse. We'll need this in master uncommented eventually (when upgrading to Clang 12).

For me personally I already have the patch in my repo, but I'm hopefully not the only one building Bitcoin Core with the latest version of Clang (to get early notification of compilation issues/compiler bugs, to get the best libFuzzer and diagnostics goodies, etc.) we support so I thought it would be helpful to upstream it commented out for now :)

practicalswift

comment created time in 7 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha 2838284adb469982dfaa1787ac327325e752f3a4

Add practicalswift

view details

push time in 8 days

pull request commentbitcoin/bitcoin

Per-Peer Message Capture

Removed my ACK (temporarily) in light of @MarcoFalke's comment about the unrelated change in src/net.cpp.

Hopefully that will be resolved soon and I'd be glad to re-review :)

troygiorshev

comment created time in 8 days

PR opened dennisreimann/bitcoindevlist.com

Add practicalswift

Add practicalswift :)

+12 -0

0 comment

1 changed file

pr created time in 8 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha 70347fb05236d7d8f091719c68c400ace3870ef6

Add practicalswift

view details

push time in 8 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha 2cdc449dd27934d33be994130d0c16ef54e23374

Add practicalswift

view details

push time in 8 days

pull request commentbitcoin/bitcoin

Per-Peer Message Capture

re-ACK 9a9314aa454c88a577260406fed3cb391dc4e4a7: diff still looks correct

Looking forward to having this neat feature in master!

troygiorshev

comment created time in 8 days

push eventpracticalswift/bitcoindevlist.com

practicalswift

commit sha f34d2b2fbccfc58a4f2dc0ee7d670ef8045277b7

Add practicalswift

view details

push time in 8 days

create barnchpracticalswift/bitcoindevlist.com

branch : practicalswift

created branch time in 8 days

fork practicalswift/bitcoindevlist.com

Support bitcoin developers so they can focus on building our future.

https://bitcoindevlist.com

fork in 8 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha 7a550205e2fcf34af9305567771cbfbde894443d

Add GitHub Codespaces integration

view details

push time in 8 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha c17aea9a4928b3519605619a57bd066c3276b398

Add GitHub Codespaces integration

view details

push time in 8 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha 525079642a16b225b1d41a63d64188248f5f49b0

minimal

view details

push time in 9 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha f4347fdea0c80118e9a1257eecaa1f763d7cd9a6

Add GitHub Codespaces integration

view details

practicalswift

commit sha c536cd0f93c2e36d2543c95abab7d60082c840f7

minimal

view details

push time in 9 days

pull request commentbitcoin/bitcoin

build: optionally skip external warnings

ACK ba8950ee0134a7958e3e9b041cd54d222feb09a1: diff looks correct!

Really looking forward to having this in master :)

vasild

comment created time in 9 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha 12c47a157b7e8a72bb528fc3a810c3802d9c2d7b

bear-make-j-2

view details

practicalswift

commit sha 97818fbc4c860b5cf7162e5230789f205af8e9ef

fixup

view details

push time in 9 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha c57f9299c7dba78cf61c391ae5594dfc2084a01f

unminimize

view details

push time in 9 days

push eventpracticalswift/bitcoin

practicalswift

commit sha b0287dc4fa83e5d3c95edbf9bc120e222f9e1a22

log: Print name of the logging function (-logfunctionnames) in functional and unit tests

view details

push time in 9 days

Pull request review commentbitcoin/bitcoin

log: Prefix log messages with function name if -logfunctionnames is set

 def __init__(self, i, datadir, *, chain, rpchost, timewait, timeout_factor, bitc          if self.version_is_at_least(190000):             self.args.append("-logthreadnames")+        if self.version_is_at_least(200000):

Oh, thanks! Fix pushed.

practicalswift

comment created time in 9 days

PullRequestReviewEvent

push eventpracticalswift/bitcoin

practicalswift

commit sha b9a2c648a4cfd034cc1d8362e8bb36ebc8be03bc

log: Print name of the logging function (-logfunctionnames) in functional and unit tests

view details

push time in 9 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha 8903a2bbeb06e3dd134468cfb8a419f8bb1a5c61

bear-ake

view details

push time in 9 days

Pull request review commentbitcoin/bitcoin

log: Mitigate disk filling attacks by temporarily rate limiting LogPrintf(…)

 void BCLog::Logger::LogPrintStr(const std::string& str)      str_prefixed = LogTimestampStr(str_prefixed); +    // Rate limit logging to disk to avoid disk filling attacks.+    bool skip_writing_to_disk_due_to_rate_limiting{false};+    if (!skip_disk_usage_rate_limiting) {+        const std::chrono::seconds now = GetTime<std::chrono::seconds>();+        if ((now - m_last_reset_of_bytes_logged_per_source_location) > std::chrono::hours{1}) {+            m_bytes_logged_per_source_location.clear();+            m_last_reset_of_bytes_logged_per_source_location = now;+        }+        m_bytes_logged_per_source_location[source_location] += str_prefixed.size();+        if (m_bytes_logged_per_source_location[source_location] > HOURLY_LOG_QUOTA_IN_BYTES_PER_SOURCE_LOCATION) {+            const bool print_quota_state_change_message = (m_bytes_logged_per_source_location[source_location] - str_prefixed.size()) <= HOURLY_LOG_QUOTA_IN_BYTES_PER_SOURCE_LOCATION;+            if (print_quota_state_change_message) {+                str_prefixed = LogTimestampStr(strprintf("Excessive logging detected from %s:%d (%s): >%d MiB logged during the last hour. Suppressing logging to disk from this source location for up to one hour. Console logging unaffected. Last log entry: %s", source_location.first, source_location.second, logging_function, HOURLY_LOG_QUOTA_IN_BYTES_PER_SOURCE_LOCATION / (1024 * 1024), str_prefixed));+            } else {+                skip_writing_to_disk_due_to_rate_limiting = true;

Makes sense. I'll implement.

practicalswift

comment created time in 9 days

PullRequestReviewEvent

Pull request review commentbitcoin/bitcoin

log: Mitigate disk filling attacks by temporarily rate limiting LogPrintf(…)

 void BCLog::Logger::LogPrintStr(const std::string& str)      str_prefixed = LogTimestampStr(str_prefixed); +    // Rate limit logging to disk to avoid disk filling attacks.+    bool skip_writing_to_disk_due_to_rate_limiting{false};+    if (!skip_disk_usage_rate_limiting) {+        const std::chrono::seconds now = GetTime<std::chrono::seconds>();+        if ((now - m_last_reset_of_bytes_logged_per_source_location) > std::chrono::hours{1}) {+            m_bytes_logged_per_source_location.clear();+            m_last_reset_of_bytes_logged_per_source_location = now;

That's a good idea. I'll implement!

practicalswift

comment created time in 9 days

PullRequestReviewEvent

pull request commentbitcoin/bitcoin

log: Mitigate disk filling attacks by temporarily rate limiting LogPrintf(…)

@MarcoFalke

Conceptually, I am not sure if it is good to fight the symptoms.

I fail to see how introducing a mitigation would be to "fight the symptoms".

The reason we use ASLR for example isn't that we've given up on the ambition to write vulnerability free code :)

The reason we're using mitigations is to make exploitation harder and hopefully turn a vulnerability into a normal bug.

Have you looked at the implementation in this PR? :)

The mitigation logic would only kick in in under extreme circumstances meaning that the only observable difference from a user perspective is that his/her node would be exploitable to disk fill attacks without the mitigation in place, whereas he/she would be safe with it.

Note that this is not a theoretical issue: we've had exploitable disk filling vulnerabilities in the past which this mitigation would have successfully turned into just another non-exploitable non-security bug.

I'd prefer if unconditional logs were only used for the init/shutdown sequence and local system errors, such as data corruption. Anything else the average user probably doesn't care about, and if they did, they could enable the corresponding debug category and provide enough disk space for the debug log file.

I agree that we should log more conservatively and ideally leave no room for disk filling attacks, but that doesn't preclude also protecting our users in case we fail to do so :)

practicalswift

comment created time in 9 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha aadccc377a2ff64dd9bc8fda3a268cb7f857dcb3

Add GitHub Codespaces integration

view details

practicalswift

commit sha df8a2998fae3f99c0a0b497813c57c8db57c1b44

add-shellcheck-plugin

view details

practicalswift

commit sha 20fdf3691d2e039139f48dad5e17ea536ba41d9d

fixup

view details

push time in 9 days

issue commentbitcoin/bitcoin

fuzz: how to scale fuzzing with the number of fuzz targets

Thanks for the ping @fanquake!

When doing large scale fuzzing with the goal of reaching as good coverage as possible I think we definitely need support for one-binary-per-target.

Don't take my word for it though: @kcc of C++ sanity fame who introduced the sanitizers, libFuzzer, OSS-Fuzz, CFI, etc. wrote this in https://github.com/bitcoin/bitcoin/issues/11045#issuecomment-334516409: "I always advocate for one-binary-per-target because it makes fuzzing more efficient." :)

With that said I think it could make sense to add a configure option which would build the fuzzing harnesses as one binary (with individual targets selected as a runtime argument) to speed up normal day-to-day compilation. That could hopefully be enabled by default to make sure the fuzzing harnesses still compiles are non-fuzzing code changes (currently that is often noticed only at CI stage).

Would that make sense?

MarcoFalke

comment created time in 9 days

pull request commentbitcoin/bitcoin

[0.20] build: set minimum required Boost to 1.48.0

ACK 3562c15be3dbf725197d719d58c8d78e2f2c6779: correct is better than incorrect :)

fanquake

comment created time in 9 days

pull request commentbitcoin/bitcoin

net: Assume that SetCommonVersion is called at most once per peer

ACK fab93637867217266a810794d179487bb1eb8c69: patch looks correct

MarcoFalke

comment created time in 9 days

pull request commentbitcoin/bitcoin

Restore compatibility with old CSubNet serialization

Concept ACK

sipa

comment created time in 9 days

pull request commentbitcoin/bitcoin

Avoid the use of abs64 in timedata

ACK d1292f25f272401da0c58580521c74b1fa03a9ad

sipa

comment created time in 9 days

pull request commentbitcoin/bitcoin

net: Assume that SetCommonVersion is called at most once per peer

Concept ACK

While touching src/util/check.h, would you mind cherry-picking in 91bdd439987fb3f24f9b841fe88b3cf416b38f48 from #20122 to make Assert(…) usable in all contexts?

MarcoFalke

comment created time in 9 days

Pull request review commentbitcoin/bitcoin

validation: Increase robustness when loading malformed mempool.dat files (LoadMempool)

 bool LoadMempool(CTxMemPool& pool)         for (const auto& i : mapDeltas) {             if (FeeDeltaRange(i.second)) {                 pool.PrioritiseTransaction(i.first, i.second);+            } else {+                if (i.second != 0) {

You're absolutely right: the conditional is redundant. Thanks for noticing! Redundancy removed :)

Please re-review! :)

practicalswift

comment created time in 9 days

PullRequestReviewEvent

push eventpracticalswift/bitcoin

practicalswift

commit sha 875a2c3149f6f94b198c7c24230375d27410f422

Print log message in case of a corrupt mempool.dat file

view details

push time in 9 days

PR opened bitcoin/bitcoin

tests: Update UBSan suppressions file with suppressions needed for clang 12 (current trunk)

Update UBSan suppressions file with suppressions needed for clang 12 (current trunk).

+26 -0

0 comment

1 changed file

pr created time in 9 days

push eventpracticalswift/bitcoin

practicalswift

commit sha 32272298617d4f8134d55b06c4b4cbcdfd7688c6

tests: Update UBSan suppressions file with suppressions needed for clang 12 (current trunk)

view details

push time in 9 days

create barnchpracticalswift/bitcoin

branch : clang-12-ubsan-suppressions

created branch time in 9 days

issue openedbitcoin/bitcoin

UBSan warning when fuzzing abs64(...)

When extending the test/fuzz/integer fuzzer I noticed the following UBSan warning when fuzzing abs64(...):

runtime error: negation of -9223372036854775808 cannot be represented in type 'int64_t' (aka 'long'); cast to an unsigned type to negate this value to itself

Fuzzing harness:

diff --git a/src/test/fuzz/integer.cpp b/src/test/fuzz/integer.cpp
index 35d6804d4..bc158e5a2 100644
--- a/src/test/fuzz/integer.cpp
+++ b/src/test/fuzz/integer.cpp
@@ -40,6 +40,8 @@
 #include <set>
 #include <vector>

 void initialize()
 {
     SelectParams(CBaseChainParams::REGTEST);
@@ -82,6 +84,7 @@ void test_one_input(const std::vector<uint8_t>& buffer)
     (void)ComputeMerkleRoot(v256);
     (void)CountBits(u64);
     (void)DecompressAmount(u64);
+    (void)abs64(i64);
     (void)FormatISO8601Date(i64);
     (void)FormatISO8601DateTime(i64);
     // FormatMoney(i) not defined when i == std::numeric_limits<int64_t>::min()

Typically abs(I n) type functions are not defined when n == std::numeric_limits<I>::min() so it could be argued that this is expected, but perhaps the function could be rewritten in a way which guarantees that it gives the same behaviour across systems (instead of UB).

created time in 9 days

pull request commentbitcoin/bitcoin

validation: Increase robustness when loading malformed mempool.dat files (LoadMempool)

@theStack Now printing a log message. Please re-review :)

practicalswift

comment created time in 10 days

push eventpracticalswift/bitcoin

practicalswift

commit sha 89ab5c24586dfb2bcde34ed4b9d706a4cdde3bc8

Print log message in case of a corrupt mempool.dat file

view details

push time in 10 days

pull request commentbitcoin/bitcoin

net: Prevent routing of deprecated Site Local IPv6

An example from mainnet where Bitcoin Core tries to connect to a fec0::/10 address learned from a mainnet peer.

The connections is blocked by Tor:

Oct 10 12:34:56.000 [warn] Rejecting SOCKS request for anonymous connection to private address fec0::5b4f:fa94:a34b:1731.
n-thumann

comment created time in 10 days

push eventbitcoin-codespaces/bitcoin

practicalswift

commit sha e7adc262f3d53d2fecd74210544c14de84ee8d18

Add GitHub Codespaces integration

view details

practicalswift

commit sha bd923f4c0e360bfc69c033f26685a6520403be98

simplification

view details

push time in 10 days

more