5a96767e3f depends, libevent: Do not install *.pc files and remove patches for them (Hennadii Stepanov)
ffda355b5a cmake, refactor: Move `HAVE_EVHTTP_...` to `libevent` interface (Hennadii Stepanov)
b619bdc330 cmake: Revamp `FindLibevent` module (Hennadii Stepanov)
Pull request description:
This PR generalizes the use of `find_package` / `pkg_check_modules`, prioritizing the former.
Addresses https://github.com/bitcoin/bitcoin/pull/30903#issuecomment-2444700876:
> We should also follow up with refactoring the libevent module, to more generically use CMake/pkg-config, rather than restricting the CMake usage to `vcpkg`. At that point, we'd likely be able to dump pkg-config for the depends path entirely.
Similar to https://github.com/bitcoin/bitcoin/pull/30903.
ACKs for top commit:
fanquake:
ACK 5a96767e3f
Tree-SHA512: 181020c16ccd2821e718c73f264badcdc5e62980c4a8d9691e759efe2ea00da2326e26308d1dcfdeac01e9e27930428ecace9f36941deee951b751b138d7266c
e2ba823671 depends: Specify CMake generator explicitly (Hennadii Stepanov)
Pull request description:
Building packages in depends implies using GNU Make. However, this assumption can be wrong in environments where the [`CMAKE_GENERATOR`](https://cmake.org/cmake/help/latest/envvar/CMAKE_GENERATOR.html) variable is set.
This change explicitly makes CMake use the "Unix Makefiles" generator.
Can be tested as follows:
```
$ env CMAKE_GENERATOR=Ninja make -C depends
```
ACKs for top commit:
fanquake:
ACK e2ba823671 - Going forward I think we should look at making this work without having to hard code anything.
Tree-SHA512: e14ed1cec192434fe089d36a83e1e150727a3b299fada80a61fa5b44b0c50e014a774ef1e6cd6df189e25f7a13042a20d4f9605f6ccd32e7782f10adaf5e788f
915640e191 depends: zeromq: don't install .pc files and remove patches for them (Cory Fields)
6b8a74463b cmake: Add `FindZeroMQ` module (Hennadii Stepanov)
Pull request description:
This PR introduces the `FindZeroMQ` module, which first attempts to find the `libzmq` library using CMake's `find_package()` and falls back to `pkg_check_modules()` if unsuccessful.
Addresses https://github.com/bitcoin/bitcoin/issues/30876 for the ZeroMQ package.
ACKs for top commit:
fanquake:
ACK 915640e191
Tree-SHA512: 2f17bae21be5d3f280a13425d22f5d1b2e23837a8aaf5ec89c433767509de030a42d598b261e102bdb5b860d8ede98013c124c3d25e081e956d4ee3a81b2584f
Building packages in depends implies using GNU Make. However, this
assumption can be wrong in environments where the `CMAKE_GENERATOR`
variable is set.
This change explicitly makes CMake use the "Unix Makefiles" generator.
40e5f26a3f mapport: remove dead code in DispatchMapPort (Antoine Poinsot)
38fdf7c1fb mapport: drop outdated comments (Antoine Poinsot)
b7b2435290 doc: add release note for #31130 (Antoine Poinsot)
1b6dec98da depends: drop miniupnpc (Antoine Poinsot)
953533d021 doc: remove mentions of UPnP (Antoine Poinsot)
94ad614482 ci: remove UPnP options (Antoine Poinsot)
a9598e5eaa build: drop miniupnpc dependency (Antoine Poinsot)
a5fcfb7385 interfaces: remove now unused 'use_upnp' arg from 'mapPort' (Antoine Poinsot)
038bbe7b20 daemon: remove UPnP support (Antoine Poinsot)
844770b05e qt: remove UPnP settings (Antoine Poinsot)
Pull request description:
This PR removes UPnP IGD support and drops our [miniupnp](https://github.com/miniupnp/miniupnp) dependency.
Miniupnpc is a C library (somewhat) maintained by a single person which had several vulnerabilities in the past (a couple dozens are listed [here](https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=miniupnp)), some of which directly affected our software ([RCE in 2015](https://bitcoincore.org/en/2024/07/03/disclose_upnp_rce/), [OOM in 2020](https://bitcoincore.org/en/2024/07/31/disclose-upnp-oom/)).
The main purpose of this functionality is to have more (non-data-center) reachable nodes on the network. For a non-technical user running Bitcoin Core at home, the software would automatically open a port on their router to receive incoming connections. This way, users not able to manually open a port on their router would still provide the network with more resources and enhance its diversity.
However, due to past vulnerabilities (and a worry about unknown future ones) in miniupnpc this feature was disabled by default in https://github.com/bitcoin/bitcoin/pull/6795. Having it disabled by default kills (most of?) the purpose of having this functionality in the first place: someone technical enough to understand the `-upnp` startup option or the "enable UPnP" setting is most likely able to open a port on his box in the first place.
In addition, laanwj implemented PCP with a NAT-PMP fallback directly in Bitcoin Core in https://github.com/bitcoin/bitcoin/pull/30043. If we ever want to re-enable automatic NAT traversal by default in Bitcoin Core, this is the best option (and in my opinion the only sane one). The NAT-PMP fallback makes it so compatibility shouldn't be (much of) an issue.
On balance, i believe that keeping this functionality and this barely maintained C dependency has higher costs than benefits. Therefore i propose that we get rid of it.
ACKs for top commit:
jarolrod:
ACK 40e5f26a3f
1440000bytes:
Code Review ACK 40e5f26a3f
laanwj:
Code review ACK 40e5f26a3f
i-am-yuvi:
Tested ACK 40e5f26a3f
Tree-SHA512: 9ea48662775510f5ec6de7af65790f7c8d211603398e9d8c634a86387be81b28081419a95b4d6680d3d7fe6a9f16cec99f16516548201dc7e49781909899a657
The description of `i686-pc-linux-gnu` and `x86_64-pc-linux-gnu` is
incomplete and inconsistent with the rest. Fix this. Also use "64 bit"
consistently instead of "64-bit".
Running Bitcoin Core on unsupported OSes may expose users to security
issues.
macOS Monterey 12 received its final security update (12.7.6) on July
2024. Apple classifies the hardware that can run macOS 12 at most as
"obsolete worldwide".
ae56b3230b depends: For mingw cross compile use -gcc-posix to prevent library conflict (laanwj)
Pull request description:
CMake parses some paths from the spec of the C compiler, assuming it will be the linker, resulting in the link to end up with `-L/usr/lib/gcc/x86_64-w64-mingw32/12-win32` on debian bookworm if both `-win32` and `-posix` variants are installed, and `-win32` is the default alternative.
This results in the wrong C++ library being linked, missing std::threads::hardware_concurrency and other threading functions.
To fix this, use the `-posix` variant of gcc as well when available. This fixes a regression compared to autotools, where this scenario worked.
ACKs for top commit:
theuni:
utACK ae56b3230b.
hebasto:
ACK ae56b3230b. I've tested on both Debian Bookworm and Ubuntu 24.04 with the `g++-mingw-w64-x86-64` package installed. The resulting CMake internal configuration appears more accurate. For instance, on Ubuntu 24.04, for the `bitcoin-tx` target, the diff in `build/src/CMakeFiles/bitcoin-tx.dir/linkLibs.rsp` looks as follows:
Tree-SHA512: f36fae50f91a29f565940494af9e46f47e219b99e329c0714ace47c516ac524602d5b6538a07488157bc2a71be7bac72176097fff3178129c5084bf6cc823167
CMake parses some paths from the spec of the C compiler, assuming it
will be the linker, resulting in the link to end up with
`-L/usr/lib/gcc/x86_64-w64-mingw32/12-win32` on debian bookworm if both
-win32 and -posix variants are installed, and -win32 is the default
alternative.
This results in the wrong C++ library being linked, missing
std::threads::hardware_concurrency and other threading functions.
To fix this, use the -posix variant of gcc as well when available. This
fixes a regression compared to autotools, where this scenario worked.
5c7cacf649 ci: Remove natpmp build option and libnatpmp dependency (laanwj)
7e7ec984da doc: Remove mention of natpmp build options (laanwj)
061c3e32a2 depends: Drop natpmp and associated option from depends (laanwj)
20a18bf6aa build: Drop libnatpmp from build system (laanwj)
7b04709862 qt: Changes for built-in PCP+NAT-PMP (laanwj)
52f8ef66c6 net: Replace libnatpmp with built-in NATPMP+PCP implementation in mapport (laanwj)
97c97177cd net: Add PCP and NATPMP implementation (laanwj)
d72df63d16 net: Use GetLocalAddresses in Discover (laanwj)
e02030432b net: Add netif utility (laanwj)
754e425438 crypto: Add missing WriteBE16 function (laanwj)
Pull request description:
Continues #30005. Closes #17012..
This PR adds PCP (Port Control Protocol) from [RFC6887](https://datatracker.ietf.org/doc/html/rfc6887). This adds, in addition to the existing IPv4 port mapping (which now uses PCP, with fallback to NAT-PMP), support for IPv6 pinholing-that is, opening a port on the firewall to make it reachable.
PCP, like NAT-PMP is a simple UDP-based protocol, and the implementation is self-contained, so this gets rid of lthe libnatpnp dependency without adding a new one. It should otherwise be a drop-in replacement. NAT-PMP fallback is implemented so this will not make router support worse.
For now it is disabled by default, though in the future (not in this PR) we could consider enable it by default to increase the number of connectable nodes without adding significant attack surface.
To test:
```bash
bitcoind -regtest -natpmp=1 -debug=net
```
(most of the changes in this PR are, ironically, removing the libnatpmp dependency and associated build system and build docs)
## TODO
- [x] Default gateway discovery on Linux / FreeBSD
- [x] Default gateway discovery on Windows
- [x] Default gateway discovery on MacOS
- [x] Either solve FreeBSD compile issue (probably upstream issue) or remove FreeBSD support
## Things to consider for follow-up PRs
- https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1658764974 avoid unreachable nets (not given to -onlynet=)
- https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1658949236 could announce an addr:port where we do not listen (no -bind)
- https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1684368824 could announce the wrong port because it uses GetListenPort()
- https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1679709347 if we requested one port but another was assigned, then which one to use in the renewal?
- https://github.com/bitcoin/bitcoin/pull/30043#discussion_r1772017020 Use `GetAdapterAddresses` to discover local addresses for Windows
ACKs for top commit:
Sjors:
ACK 5c7cacf649
achow101:
ACK 5c7cacf649
vasild:
ACK 5c7cacf649
Tree-SHA512: e35b69e56d5f5449a3d48a799f9b7b65107c65eeb3e245c2c1e9d42221e469ca5ead90afae423160601cd664dd553a51c859e04f4492f335b064aae3bf23e3bc
In the Guix environment, `${BASEPREFIX}/${HOST}/native/bin` is added to
the `PATH` environment variable, causing CMake to search for package
configurations in the `native` subdirectory first.
Explicitly specifying the top-priority search prefixes for the
`Libmultiprocess` and `LibmultiprocessNative` packages resolves the
issue.
Currently, builds of libevent in depends, using CMake, fail on some
systems, like Alpine, with the following:
```bash
/bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c: In function 'evmap_signal_add_':
/bitcoin/depends/work/build/aarch64-unknown-linux-musl/libevent/2.1.12-stable-1516ed47ea8/evmap.c:456:31: error: 'NSIG' undeclared (first use in this function)
456 | if (sig < 0 || sig >= NSIG)
```
From what I can tell the `_GNU_SOURCE` "detection" in libevents CMake build
system, never? really worked, and it's not clear what a nice fix is.
For now, always use `_GNU_SOURCE` when building libevent in depends.
Now that we use the native compiler, and have fixed Qt, and these vars
are unset it Guix, we can remove the unsetting from our compiler command
here.
Fixes#21552.
8c935e625e depends: Fix CMake-generated `libevent*.pc` files (Hennadii Stepanov)
Pull request description:
Broken out of #30454. This is a backport of the merged upstream PR: https://github.com/libevent/libevent/pull/1622.
Note that after #29835 we might end up dropping pkg-config and using the installed CMake files directly, but that depends on whether or not enough distros actually ship those files.
Either way, having fixed up .pc files won't hurt.
ACKs for top commit:
hebasto:
ACK 8c935e625e.
fanquake:
ACK 8c935e625e
Tree-SHA512: 259c2ad78fb9e90370a7205dc71c40acda1a872f6509435133bc1c4c2c3de57366e80679aa083e13ed85e7966883dc470c0147ee171a2ed0171a18cd5ffc99b3
