Bug 34082 - Recent update of lib64event7 breaks tor service
Summary: Recent update of lib64event7 breaks tor service
Status: RESOLVED FIXED
Alias: None
Product: Mageia
Classification: Unclassified
Component: RPM Packages (show other bugs)
Version: 9
Hardware: All Linux
Priority: Normal normal
Target Milestone: ---
Assignee: QA Team
QA Contact:
URL: https://bugs.gentoo.org/894536
Whiteboard: MGA9-64-OK
Keywords: advisory, validated_update
Depends on:
Blocks: 34089
  Show dependency treegraph
 
Reported: 2025-03-11 19:38 CET by steve daniewicz
Modified: 2025-03-13 20:09 CET (History)
6 users (show)

See Also:
Source RPM: tor-0.4.7.13-1.mga9
CVE:
Status comment:


Attachments

Description steve daniewicz 2025-03-11 19:38:18 CET
Description of problem:
Recent update of lib64event7 breaks tor service, and it will not start. Downgrading to the previous version of lib64event7 allows tor to start properly

Version-Release number of selected component (if applicable):
2.1.12.41

How reproducible:


Steps to Reproduce:
1.
2.
3.
Comment 1 Florian Hubold 2025-03-11 21:53:16 CET
Actual error message, which can only be seen by starting tor manually:

> # /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config
> /usr/bin/tor: symbol lookup error: /usr/bin/tor: undefined symbol: evutil_secure_rng_add_bytes

CC: (none) => doktor5000

Comment 2 katnatek 2025-03-11 22:43:12 CET
(In reply to Florian Hubold from comment #1)
> Actual error message, which can only be seen by starting tor manually:
> 
> > # /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config
> > /usr/bin/tor: symbol lookup error: /usr/bin/tor: undefined symbol: evutil_secure_rng_add_bytes

This is very weird the update just add a symlink :S

CC: (none) => geiger.david68210

katnatek 2025-03-11 22:43:27 CET

CC: (none) => j.alberto.vc

Comment 3 katnatek 2025-03-11 23:16:03 CET
Rebuild the application helps

/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config
Mar 11 16:13:21.392 [notice] Tor 0.4.7.13 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.15, Zlib 1.2.13, Liblzma 5.4.3, Libzstd 1.5.5 and Glibc 2.36 as libc.
Mar 11 16:13:21.392 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Mar 11 16:13:21.392 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
Mar 11 16:13:21.392 [notice] Read configuration file "/etc/tor/torrc".
Configuration was valid

Assignee: bugsquad => j.alberto.vc
CC: j.alberto.vc => yvesbrungard

Comment 4 katnatek 2025-03-11 23:18:31 CET
I send the change please send the build
Comment 5 papoteur 2025-03-12 07:36:46 CET
Submitted.
I we have to rebuild all packages depending of libevent7, the list is long:
bitcoin-qt
bitcoind
ccnet
chromium-browser-stable
coturn
dogecoin-qt
dogecoind
firefox
flightgear
fvwm3
gearmand
lib64389-ds-base0
lib64avahi-libevent1
lib64ccnet0
lib64coeurl0.3
lib64event7
lib64evhtp0
lib64openmpi40
lib64openpmix2
lib64qt5webenginecore5
lib64qt6webengine-devel
lib64qt6webenginecore6
lib64unbound8
lib64verto-libevent1
libcamera-tools
libmemcached
libreswan
links
links-graphic
memcached
netatalk
nfs-utils
nodejs-electron
openmpi
perl-Event-Lib
php-event
php-memcached
php8.1-event
php8.1-memcached
qtwebengine5
seafile
sslsplit
telegram-cli
thunderbird
tmux
tor
transmission-cli
transmission-daemon
transmission-gtk3
transmission-qt6
unbound
ungoogled-chromium
Comment 6 papoteur 2025-03-12 08:46:07 CET
Submitting:
SRPMS
tor-0.4.7.13-1.1.mga9
RPMS
tor-0.4.7.13-1.1.mga9

Assignee: j.alberto.vc => qa-bugs

Comment 7 Morgan Leijström 2025-03-12 10:10:31 CET
/Boss hat on/
What can be improved in order to avoid missing to rebuild dependent packages by this reason next time?

CC: (none) => fri

Comment 8 Morgan Leijström 2025-03-12 10:44:42 CET
As libevent7 is already out, it should be top prio to rebuild and ship all dependencies to users.

Also, is it the same situation on Cauldron?

Priority: Normal => High

Comment 9 katnatek 2025-03-12 11:09:58 CET
Please don't panic

Of the list in comment#5
I test at version of transmission  without issues
, chromium-browser is a false positive if you
use the -f switch you see are older versions
https://bugs.mageia.org/show_bug.cgi?id=34063#c8

Firefox and Thunderbird are updated now so
should be fine
ungoogled chromium is not our bussnes is from mlo

new flightgear is in qa stage
I will check more later

The more possible candidate are the bitcoin
related as could use the same functions that tor
Comment 10 papoteur 2025-03-12 12:07:10 CET
I have compared exported symbols from old libevent and new one, using readelf.
The significant differences are:
 diff -u  libevent7-old.txt libevent7.txt| grep "[+-]"
--- libevent7-old.txt   2025-03-12 11:22:04.544647582 +0100
+++ libevent7.txt       2025-03-12 11:19:13.589275110 +0100               
-__poll_chk@GLIBC_2.16 (7)                 
+arc4random_buf@GLIBC_2.36 (4)              
+arc4random@GLIBC_2.36 (4) 
-evutil_secure_rng_add_bytes
-getrandom@GLIBC_2.25 (15)
+poll@GLIBC_2.2.5 (2)

I presume that the difference comes from some detected external conditions, but I don't understand what, for now.
In util.h the missing symbol is included in the following test:

#if !defined(EVENT__HAVE_ARC4RANDOM) || defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)

but I don't know how these variables are defined.

Priority: High => Normal

Comment 11 katnatek 2025-03-12 17:11:21 CET
(In reply to papoteur from comment #10)
> I have compared exported symbols from old libevent and new one, using
> readelf.
> The significant differences are:
>  diff -u  libevent7-old.txt libevent7.txt| grep "[+-]"
> --- libevent7-old.txt   2025-03-12 11:22:04.544647582 +0100
> +++ libevent7.txt       2025-03-12 11:19:13.589275110 +0100               
> -__poll_chk@GLIBC_2.16 (7)                 
> +arc4random_buf@GLIBC_2.36 (4)              
> +arc4random@GLIBC_2.36 (4) 
> -evutil_secure_rng_add_bytes
> -getrandom@GLIBC_2.25 (15)
> +poll@GLIBC_2.2.5 (2)
> 
> I presume that the difference comes from some detected external conditions,
> but I don't understand what, for now.
> In util.h the missing symbol is included in the following test:
> 
> #if !defined(EVENT__HAVE_ARC4RANDOM) ||
> defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
> 
> but I don't know how these variables are defined.

I think the build against updated glibc could trigger the issue but I just not sure why tor is more sensitive to this
Comment 12 katnatek 2025-03-12 17:37:33 CET
Packages:

tor-0.4.7.13-1.1.mga9

SRPM

tor-0.4.7.13-1.1.mga9

Minimal test

before the update

/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config

shows the message in comment#1

after the update the command show an output as comment#3
katnatek 2025-03-12 17:58:18 CET

Blocks: (none) => 34089

Comment 13 katnatek 2025-03-12 17:59:21 CET
I open a bug to check all the other packages
Comment 14 katnatek 2025-03-12 20:00:46 CET
RH x86_64

 LC_ALL=C urpmi tor
To satisfy dependencies, the following packages are going to be installed:
  Package                        Version      Release       Arch    
(medium "Core Release")
  lib64tsocks1                   1.8          0.beta5.22.m> x86_64  
  tor                            0.4.7.13     1.mga9        x86_64  
  tsocks                         1.8          0.beta5.22.m> x86_64  
17MB of additional disk space will be used.
3MB of packages will be retrieved.
Proceed with the installation of the 3 packages? (Y/n) y


    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/lib64tsocks1-1.8-0.beta5.22.mga9.x86_64.rpm
    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/tor-0.4.7.13-1.mga9.x86_64.rpm                 
    https://mirror.math.princeton.edu/pub/mageia/distrib/9/x86_64/media/core/release/tsocks-1.8-0.beta5.22.mga9.x86_64.rpm          
installing tsocks-1.8-0.beta5.22.mga9.x86_64.rpm tor-0.4.7.13-1.mga9.x86_64.rpm lib64tsocks1-1.8-0.beta5.22.mga9.x86_64.rpm from /var/cache/urpmi/rpms
Preparing...                     ##################################################################################################
      1/3: lib64tsocks1          ##################################################################################################
      2/3: tsocks                ##################################################################################################
      3/3: tor                   ##################################################################################################


/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config
/usr/bin/tor: symbol lookup error: /usr/bin/tor: undefined symbol: evutil_secure_rng_add_bytes


LC_ALL=C urpmi --auto --auto-update 
medium "Core Release (Installer) (DVD1)" is up-to-date
medium "Nonfree Release (Installer) (DVD2)" is up-to-date
medium "QA Testing (64-bit)" is up-to-date
medium "Core Release" is up-to-date
medium "Core Updates" is up-to-date
medium "Nonfree Release" is up-to-date
medium "Nonfree Updates" is up-to-date
medium "Tainted Release" is up-to-date
medium "Tainted Updates" is up-to-date
medium "Core 32bit Release" is up-to-date
medium "Core 32bit Updates" is up-to-date
medium "Nonfree 32bit Release" is up-to-date
medium "Nonfree 32bit Updates" is up-to-date
medium "Tainted 32bit Release" is up-to-date
medium "Tainted 32bit Updates" is up-to-date
medium "BDK-Free-x86_64" is up-to-date
medium "BDK-Free-noarch" is up-to-date
medium "BDK-NonFree-x86_64" is up-to-date


installing tor-0.4.7.13-1.1.mga9.x86_64.rpm from //home/katnatek/qa-testing/x86_64
Preparing...                     ##################################################################################################
      1/1: tor                   ##################################################################################################
      1/1: removing tor-0.4.7.13-1.mga9.x86_64
                                 ##################################################################################################

/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --verify-config
Mar 12 12:56:48.997 [notice] Tor 0.4.7.13 running on Linux with Libevent 2.1.12-stable, OpenSSL 3.0.15, Zlib 1.2.13, Liblzma 5.4.3, Libzstd 1.5.5 and Glibc 2.36 as libc.
Mar 12 12:56:48.997 [notice] Tor can't help you if you use it wrong! Learn how to be safe at https://support.torproject.org/faq/staying-anonymous/
Mar 12 12:56:48.997 [notice] Read configuration file "/usr/share/tor/defaults-torrc".
Mar 12 12:56:48.997 [notice] Read configuration file "/etc/tor/torrc".
Configuration was valid

Feel free of provide more test
Comment 15 katnatek 2025-03-12 21:21:19 CET
RH x86_64

Reference: bug#31414 comment#3

systemctl start tor
systemctl -l status tor
● tor.service - Anonymizing overlay network for TCP
     Loaded: loaded (/usr/lib/systemd/system/tor.service; disabled; preset: disabled)
     Active: active (running) since Wed 2025-03-12 13:56:21 CST; 13s ago
    Process: 12888 ExecStartPre=/usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc --veri>
   Main PID: 12926 (tor)
      Tasks: 1 (limit: 6903)
     Memory: 15.5M
        CPU: 311ms
     CGroup: /system.slice/tor.service
             └─12926 /usr/bin/tor --runasdaemon 0 --defaults-torrc /usr/share/tor/defaults-torrc -f /etc/tor/torrc

mar 12 13:56:20 jgrey.phoenix Tor[12926]: Opened Socks listener connection (ready) on 127.0.0.1:9050
mar 12 13:56:20 jgrey.phoenix Tor[12926]: Parsing GEOIP IPv4 file /usr/share/tor/geoip.
mar 12 13:56:20 jgrey.phoenix Tor[12926]: Parsing GEOIP IPv6 file /usr/share/tor/geoip6.
mar 12 13:56:21 jgrey.phoenix Tor[12926]: Bootstrapped 0% (starting): Starting
mar 12 13:56:21 jgrey.phoenix Tor[12926]: Starting with guard context "default"
mar 12 13:56:21 jgrey.phoenix Tor[12926]: Signaled readiness to systemd
mar 12 13:56:21 jgrey.phoenix systemd[1]: Started tor.service.
mar 12 13:56:22 jgrey.phoenix Tor[12926]: Opening Control listener on /run/tor/control
mar 12 13:56:22 jgrey.phoenix Tor[12926]: Opened Control listener connection (ready) on /run/tor/control
mar 12 13:56:22 jgrey.phoenix Tor[12926]: Bootstrapped 5% (conn): Connecting to a relay

I don't know what I'm doing wrong
The log say 
Socks version 67 not recognized. (This port is not an HTTP proxy; did you want to use HTTP 

when try to make a connection from firefox
Comment 16 Morgan Leijström 2025-03-12 21:31:53 CET
This page I wrote a while ago might help
https://wiki.mageia.org/en/Tor,_The_Onion_Router
Comment 17 katnatek 2025-03-12 22:33:03 CET
(In reply to Morgan Leijström from comment #16)
> This page I wrote a while ago might help
> https://wiki.mageia.org/en/Tor,_The_Onion_Router

OK I was fill the wrong field, :P it works

Whiteboard: (none) => MGA9-64-OK
CC: (none) => andrewsfarm

katnatek 2025-03-12 23:52:13 CET

Source RPM: (none) => tor-0.4.7.13-1.mga9

Comment 18 katnatek 2025-03-12 23:57:19 CET
(In reply to papoteur from comment #10)
> I have compared exported symbols from old libevent and new one, using
> readelf.
> The significant differences are:
>  diff -u  libevent7-old.txt libevent7.txt| grep "[+-]"
> --- libevent7-old.txt   2025-03-12 11:22:04.544647582 +0100
> +++ libevent7.txt       2025-03-12 11:19:13.589275110 +0100               
> -__poll_chk@GLIBC_2.16 (7)                 
> +arc4random_buf@GLIBC_2.36 (4)              
> +arc4random@GLIBC_2.36 (4) 
> -evutil_secure_rng_add_bytes
> -getrandom@GLIBC_2.25 (15)
> +poll@GLIBC_2.2.5 (2)
> 
> I presume that the difference comes from some detected external conditions,
> but I don't understand what, for now.
> In util.h the missing symbol is included in the following test:
> 
> #if !defined(EVENT__HAVE_ARC4RANDOM) ||
> defined(EVENT__HAVE_ARC4RANDOM_ADDRANDOM)
> 
> but I don't know how these variables are defined.

The gentoo link in the URL field explain better what happen and the solution is the
same, I think we must let of searching ghost in  bug#34089
katnatek 2025-03-12 23:57:31 CET

Keywords: (none) => advisory

Comment 19 Thomas Andrews 2025-03-13 18:59:01 CET
Validating.

CC: (none) => sysadmin-bugs
Keywords: (none) => validated_update

Comment 20 Mageia Robot 2025-03-13 20:09:04 CET
An update for this issue has been pushed to the Mageia Updates repository.

https://advisories.mageia.org/MGAA-2025-0027.html

Resolution: (none) => FIXED
Status: NEW => RESOLVED


Note You need to log in before you can comment on or make changes to this bug.