💬 darosior commented on pull request "Signing support for Miniscript Descriptors":
(https://github.com/bitcoin/bitcoin/pull/24149#discussion_r1109682908)
https://github.com/bitcoin/bitcoin/pull/27117

💬 hebasto commented on pull request "build: Propagate user-defined tools to native packages":
(https://github.com/bitcoin/bitcoin/pull/23571#issuecomment-1434524289)
Closing. Up for grabs.

✅ hebasto closed a pull request: "build: Propagate user-defined tools to native packages"
(https://github.com/bitcoin/bitcoin/pull/23571)

💬 ajtowns commented on pull request "doc: clarify that LOCK() does AssertLockNotHeld() internally":
(https://github.com/bitcoin/bitcoin/pull/27116#issuecomment-1434539481)
These aren't precisely the same (maybe they should be?). With `AssertLockNotHeld` you just get a report on that lock, on stderr:

```
Assertion failed: lock flock held in net.cpp:1398; locks held:
'flock' in net.cpp:1404 (in thread 'dnsseed')
```

with a bare `LOCK()` you get a less useful report on stderr (it only shows the location of the second lock attempt, not where it's being held):

```
Assertion failed: detected double lock for 'flock' in net.cpp:1399 (in thread 'dnsseed'), det
...

💬 Sjors commented on pull request "contrib: remove install_db4.sh":
(https://github.com/bitcoin/bitcoin/pull/26834#issuecomment-1434541595)
Post merge: just noticed the script was gone, but the bdb-only-depends approach works.

📝 fanquake opened a pull request: "depends: harden libevent"
(https://github.com/bitcoin/bitcoin/pull/27118)
Turn on libevents own hardening option (`--enable-gcc-hardneing`, although the options are not GCC specific), and backport a commit I upstreamed (https://github.com/libevent/libevent/pull/1418) to use `FORTIFY_SOURCE=3` over 2.

Solves half of #27038, by giving us some fortified funcs in `bitcoin-cli`.
Also elated to #27027.

🤔 vasild requested changes to a pull request: "p2p: return `CSubNet` in `LookupSubNet`"
(https://github.com/bitcoin/bitcoin/pull/26078)

💬 vasild commented on pull request "p2p: return `CSubNet` in `LookupSubNet`":
(https://github.com/bitcoin/bitcoin/pull/26078#discussion_r1109707211)
nit: maybe add `assert(!subnet.IsValid());` after `CSubNet subnet;` to make it obvious that we return an invalid object and to guard against future changes that construct a valid `CSubNet` by default.

💬 vasild commented on pull request "p2p: return `CSubNet` in `LookupSubNet`":
(https://github.com/bitcoin/bitcoin/pull/26078#discussion_r1109701750)
nit, here and elsewhere:

```suggestion
const CSubNet subnet = LookupSubNet(strAllow);
```

💬 vasild commented on pull request "p2p: return `CSubNet` in `LookupSubNet`":
(https://github.com/bitcoin/bitcoin/pull/26078#discussion_r1109711519)
Hmm, `possibleSubnet.has_value()` will always be `true`. I guess this is an artifact from a previous incarnation of this PR that used `std::optional`.

💬 vasild commented on pull request "p2p: return `CSubNet` in `LookupSubNet`":
(https://github.com/bitcoin/bitcoin/pull/26078#discussion_r1109752206)
Now `ResolveSubNet()` is identical to `LookupSubNet()`. Maybe ditch the former and change the callers to use directly `LookupSubNet()`?

💬 vasild commented on pull request "p2p: return `CSubNet` in `LookupSubNet`":
(https://github.com/bitcoin/bitcoin/pull/26078#discussion_r1109749273)
`x || !x` will never be `false`. It suffices to change this to `(void)LookupSubNet(name);`.

💬 llazzaro commented on pull request "lint: enable E722 do not use bare except":
(https://github.com/bitcoin/bitcoin/pull/25867#issuecomment-1434618912)
Thanks for reviewing my code. I've identified a bare except statement that could catch exceptions it shouldn't. To improve code quality and precision, I've enabled the E722 flag.

This will help make the code more maintainable and avoid potential issues. I'm committed to following best practices and making more contributions to improve the project. Let me know if you have any further concerns.

💬 RazvanML commented on issue "Wallet passphrases silently ignore everything after a null character":
(https://github.com/bitcoin/bitcoin/issues/27067#issuecomment-1434642425)
Even if fixed, the change will bring a backwards compatibility problem. People who already have the passphrase containing a zero will experience a failure until they truncate the existing passphrase.

📝 furszy review_request_removed a pull request: "refactor: wallet, remove global 'ArgsManager' dependency"
(https://github.com/bitcoin/bitcoin/pull/26889)
Structurally, the wallet class shouldn't access the global `ArgsManager` class, its internal behavior shouldn't be coupled to a global command line args parsing object.

So this PR migrates the only two places where we depend on it: (1) the keypool size, and (2) the "-walletnotify" script. And cleans up the, now unneeded, wallet `ArgsManager` ref member.

Extra note:
In the process of removing the args ref member, discovered and fixed files that were invalidly depending on the wallet header
...

💬 RazvanML commented on issue "Wallet passphrases silently ignore everything after a null character":
(https://github.com/bitcoin/bitcoin/issues/27067#issuecomment-1434650979)
How about starting with a warning that the string contains a zero and only NN characters will be used? IMHO the backward compatibility issue is the major concern.

💬 vasild commented on pull request "doc: clarify that LOCK() does AssertLockNotHeld() internally":
(https://github.com/bitcoin/bitcoin/pull/27116#issuecomment-1434668609)
Do you think that this is a blocker for this PR?

💬 ajtowns commented on pull request "doc: clarify that LOCK() does AssertLockNotHeld() internally":
(https://github.com/bitcoin/bitcoin/pull/27116#issuecomment-1434721167)
> Do you think that this is a blocker for this PR?

I was just intending to note the difference not express an opinion (which I don't really have at this point). Would be nicer if the approach this PR recommends was clearly better in every way, though.

💬 fanquake commented on pull request "depends: harden libevent":
(https://github.com/bitcoin/bitcoin/pull/27118#issuecomment-1434731916)
Changed the approach here, from using libevents own hardening option (might send some fixes upstream), and a patch, to just using `FORTIFY_SOURCE` directly. That gets as what we want at the moment, without other potential side effects.

💬 fanquake commented on pull request "security-check: test for `_FORTIFY_SOURCE` usage in release binaries":
(https://github.com/bitcoin/bitcoin/pull/27038#issuecomment-1434735372)
> bitcoin-cli is fixed once we fortify libevent.

Rebased on #27118

💬 fanquake commented on pull request "refactor: don't avoid sys/types.h when building for Windows":
(https://github.com/bitcoin/bitcoin/pull/27098#issuecomment-1434738735)
Just going to combine this into #26832.