Summary: | dev-libs/libevent changes API based on the presence of arc4random in libc (net-vpn/tor: undefined symbol: evutil_secure_rng_add_bytes) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | poncho <poncho> |
Component: | Current packages | Assignee: | Michał Górny <mgorny> |
Status: | CONFIRMED --- | ||
Severity: | normal | CC: | ajak, floppym, poncho, redblade7, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=869722 https://github.com/libevent/libevent/issues/1393 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
poncho
2023-02-15 09:13:03 UTC
This seems quite strange. Did you have the "threads" USE flag disabled before the dev-libs/libevent update? The evutil_secure_rng_add_bytes function is defined behind the following preprocessor check: #if !defined(EVENT__HAVE_ARC4RANDOM) || defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM) In other words, evutil_secure_rng_add_bytes is defined only if libc does not define arc4random or libc defines both arc4random and arc4random_addrandom. The arc4random function was added in glibc-2.36. glibc does not currently implement the arc4random_addrandom function. So, here's what I think happened: 1. libevent was built against an old version of glibc that lacks arc4random. 2. tor was built against libevent with evutil_secure_rng_add_bytes defined. 3. glibc was upgraded to >=2.36. 4. libevent was rebuilt against the new glibc, causing it to lose the evutil_secure_rng_add_bytes symbol. 5. tor was rebuilt, and no longer tries to call since the configure test failed evutil_secure_rng_add_bytes. I think we could just revbump net-vpn/tor as a workaround. (In reply to Mike Gilbert from comment #1) > This seems quite strange. Did you have the "threads" USE flag disabled > before the dev-libs/libevent update? I haven't set the "threads" USE flag manually, no. Neither enabled nor disabled. Right, per comment 2, this has nothing to do with the "threads" USE flag change. What a mess. So to summarize: 1) the function disappears because it's not supported with glibc's ARC4 2) upstream thinks disappearing it is better for security than making it a no-op 3) …so effectively reverse dependencies like net-vpn/tor make the call conditional, and that has exactly the same effect Sigh. I'll revbump net-vpn/tor anyway, and add >= dep on revbumped dev-libs/libevent to hopefully force a rebuild. I think we don't need to assume anyone's still using glibc < 2.36 at this point, right? The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d39311be33fb0888563bb3b1e250f7847ef39c29 commit d39311be33fb0888563bb3b1e250f7847ef39c29 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2023-02-17 05:41:37 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2023-02-17 06:21:18 +0000 net-vpn/tor: Force rebuild along with libevent due to ABI change Revbump net-vpn/tor and require revbumped dev-libs/libevent to ensure that both are rebuilt with the >=sys-libs/glibc-2.36 as that causes libevent to change ABI. Bug: https://bugs.gentoo.org/894536 Bug: https://github.com/libevent/libevent/issues/1393 Signed-off-by: Michał Górny <mgorny@gentoo.org> net-vpn/tor/{tor-0.4.7.13.ebuild => tor-0.4.7.13-r1.ebuild} | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) |