[Bug 280345] ports-mgmt/pkg: pkg segfault when OpenSSL legacy provider is enabled

In reply to: bugzilla-noreply_a_freebsd.org: "[Bug 280345] ports-mgmt/pkg: pkg segfault when OpenSSL legacy provider is enabled"
Go to: [ bottom of page ] [ top of archives ] [ this month ]
From: <bugzilla-noreply_at_freebsd.org>
Date: Sun, 01 Mar 2026 10:15:17 UTC
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=280345

--- Comment #6 from Tassilo Philipp <tphilipp@potion-studios.com> ---
Some more info:

- this only happens when the repo url uses scheme https:// or pkg+https://
- this does not depend on the pkg repo in use (e.g. same behaviour if I use the
freebsd pkg repo or an own, custom (poudriere) repo)
- this happens when the openssl legacy provider is enabled, despite it not
being required (without it it works fine, with only the non-legacy ciphers and
stuff)

A pkg -ddd output ends like this (on 14.3 w/ pkg 2.5.1 using the freebsd pkg
repo):

---------------------

[...]
DBG(1)[67534]> (fetch) == Info: Reusing existing https: connection with host
pkgmir.geo.freebsd.org

DBG(1)[67534]> (fetch) => Send SSL data, 0000000000 bytes (0x00000000)
DBG(1)[67534]> (fetch) => Send SSL data, 0000000000 bytes (0x00000000)
DBG(1)[67534]> (fetch) => Send header, 0000000166 bytes (0x000000a6)
DBG(1)[67534]> (fetch) GET /FreeBSD:14:amd64/latest/data.pkg HTTP/1.1
DBG(1)[67534]> (fetch) Host: pkgmir.geo.freebsd.org
DBG(1)[67534]> (fetch) User-Agent: pkg/2.5.1
DBG(1)[67534]> (fetch) Accept: */*
DBG(1)[67534]> (fetch) If-Modified-Since: Wed, 25 Feb 2026 10:36:57 GMT
DBG(1)[67534]> (fetch)
DBG(1)[67534]> (fetch) == Info: Request completely sent off

DBG(1)[67534]> (fetch) <= Recv SSL data, 0000000000 bytes (0x00000000)
DBG(1)[67534]> (fetch) <= Recv SSL data, 0000000000 bytes (0x00000000)
DBG(1)[67534]> (fetch) <= Recv header, 0000000027 bytes (0x0000001b)
DBG(1)[67534]> (fetch) HTTP/1.1 304 Not Modified
DBG(1)[67534]> (fetch) <= Recv header, 0000000015 bytes (0x0000000f)
DBG(1)[67534]> (fetch) Server: nginx
DBG(1)[67534]> (fetch) <= Recv header, 0000000037 bytes (0x00000025)
DBG(1)[67534]> (fetch) Date: Sun, 01 Mar 2026 09:46:43 GMT
DBG(1)[67534]> (fetch) <= Recv header, 0000000046 bytes (0x0000002e)
DBG(1)[67534]> (fetch) Last-Modified: Wed, 25 Feb 2026 10:36:57 GMT
DBG(1)[67534]> (fetch) <= Recv header, 0000000024 bytes (0x00000018)
DBG(1)[67534]> (fetch) Connection: keep-alive
DBG(1)[67534]> (fetch) <= Recv header, 0000000025 bytes (0x00000019)
DBG(1)[67534]> (fetch) ETag: "699ed0c9-aa86b7"
DBG(1)[67534]> (fetch) <= Recv header, 0000000033 bytes (0x00000021)
DBG(1)[67534]> (fetch) X-Content-Type-Options: nosniff
DBG(1)[67534]> (fetch) <= Recv header, 0000000033 bytes (0x00000021)
DBG(1)[67534]> (fetch) X-XSS-Protection: 1; mode=block
DBG(1)[67534]> (fetch) <= Recv header, 0000000029 bytes (0x0000001d)
DBG(1)[67534]> (fetch) X-Frame-Options: SAMEORIGIN
DBG(1)[67534]> (fetch) <= Recv header, 0000000002 bytes (0x00000002)
DBG(1)[67534]> (fetch)
DBG(1)[67534]> (fetch) == Info: Connection #0 to host
pkgmir.geo.freebsd.org:443 left intact

DBG(1)[67534]> (fetch) CURL> connected to IP 2a02:80:0:3ffd::50:2
Segmentation fault

---------------------

Increasing the debug level further does not show any additional connection
specific details.

A quick test w/ command line ftp/curl recreating the exact same *logged*
request as in the debug output, works just fine:

---------------------

$ which curl
/usr/local/bin/curl
$ pkg query %v curl
8.17.0
$ curl --http1.1 -H 'Host: pkgmir.geo.freebsd.org' -H 'User-Agent: pkg/2.5.1'
-H 'Accept: */*' -H 'If-Modified-Since: Wed, 25 Feb 2026 10:36:57 GMT'
--resolve 'pkgmir.geo.freebsd.org:443:[2a02:80:0:3ffd::50:2]' -v
'https://pkgmir       <
[...]
* Established connection to pkgmir.geo.freebsd.org (2a02:80:0:3ffd::50:2 port
443) from 2003:d9:1f4a:d804:7e22:30ff:fe98:aadd port 33538
* using HTTP/1.x
> GET /FreeBSD:14:amd64/latest/data.pkg HTTP/1.1
> Host: pkgmir.geo.freebsd.org
> User-Agent: pkg/2.5.1
> Accept: */*
> If-Modified-Since: Wed, 25 Feb 2026 10:36:57 GMT
>
* Request completely sent off
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
< HTTP/1.1 304 Not Modified
< Server: nginx
< Date: Sun, 01 Mar 2026 10:00:39 GMT
< Last-Modified: Wed, 25 Feb 2026 10:36:57 GMT
< Connection: keep-alive
< ETag: "699ed0c9-aa86b7"
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block
< X-Frame-Options: SAMEORIGIN
<
* Connection #0 to host pkgmir.geo.freebsd.org:443 left intact

---------------------

However, that said:
* pkg uses curl statically (deducing this from ldd(1)), whereas ftp uses the
libcurl.so, so it's not the same
* the request I replayed is the one that also works fine with pkg, whatever it
does after that causes the segfault; that however might not be curl-related,
for comparison, a pkg -ddd output without the openssl legacy provider does not
segfault, but also does not provide any more debug output and ends with the
same line about curl:

---------------------

DBG(1)[77145]> (fetch) GET /FreeBSD:14:amd64/latest/data.pkg HTTP/1.1
DBG(1)[77145]> (fetch) Host: pkgmir.geo.freebsd.org
DBG(1)[77145]> (fetch) User-Agent: pkg/2.5.1
DBG(1)[77145]> (fetch) Accept: */*
DBG(1)[77145]> (fetch) If-Modified-Since: Wed, 25 Feb 2026 10:36:57 GMT
DBG(1)[77145]> (fetch)
DBG(1)[77145]> (fetch) == Info: Request completely sent off

DBG(1)[77145]> (fetch) <= Recv SSL data, 0000000000 bytes (0x00000000)
DBG(1)[77145]> (fetch) <= Recv SSL data, 0000000000 bytes (0x00000000)
DBG(1)[77145]> (fetch) <= Recv header, 0000000027 bytes (0x0000001b)
DBG(1)[77145]> (fetch) HTTP/1.1 304 Not Modified
DBG(1)[77145]> (fetch) <= Recv header, 0000000015 bytes (0x0000000f)
DBG(1)[77145]> (fetch) Server: nginx
DBG(1)[77145]> (fetch) <= Recv header, 0000000037 bytes (0x00000025)
DBG(1)[77145]> (fetch) Date: Sun, 01 Mar 2026 10:07:51 GMT
DBG(1)[77145]> (fetch) <= Recv header, 0000000046 bytes (0x0000002e)
DBG(1)[77145]> (fetch) Last-Modified: Wed, 25 Feb 2026 10:36:57 GMT
DBG(1)[77145]> (fetch) <= Recv header, 0000000024 bytes (0x00000018)
DBG(1)[77145]> (fetch) Connection: keep-alive
DBG(1)[77145]> (fetch) <= Recv header, 0000000025 bytes (0x00000019)
DBG(1)[77145]> (fetch) ETag: "699ed0c9-aa86b7"
DBG(1)[77145]> (fetch) <= Recv header, 0000000033 bytes (0x00000021)
DBG(1)[77145]> (fetch) X-Content-Type-Options: nosniff
DBG(1)[77145]> (fetch) <= Recv header, 0000000033 bytes (0x00000021)
DBG(1)[77145]> (fetch) X-XSS-Protection: 1; mode=block
DBG(1)[77145]> (fetch) <= Recv header, 0000000029 bytes (0x0000001d)
DBG(1)[77145]> (fetch) X-Frame-Options: SAMEORIGIN
DBG(1)[77145]> (fetch) <= Recv header, 0000000002 bytes (0x00000002)
DBG(1)[77145]> (fetch)
DBG(1)[77145]> (fetch) == Info: Connection #0 to host
pkgmir.geo.freebsd.org:443 left intact

DBG(1)[77145]> (fetch) CURL> connected to IP 2a02:80:0:3ffd::50:2

---------------------

Under gdb, this is the backtrace:

[...]
(gdb) set follow-fork-mode child
(gdb) r search blabla
Starting program: /usr/local/sbin/pkg search blabla
[Attaching after LWP 100953 of process 59697 fork to child LWP 109974 of
process 71020]
[New inferior 2 (process 71020)]
[Detaching after fork from parent process 59697]
[Inferior 1 (process 59697) detached]
[New LWP 125945 of process 71020]
[LWP 125945 of process 71020 exited]

Thread 2.1 received signal SIGSEGV, Segmentation fault.
Address not mapped to object.
[Switching to LWP 109974 of process 71020]
0x0000000800c9b8da in ?? () from /lib/libthr.so.3
(gdb) bt
#0  0x0000000800c9b8da in ?? () from /lib/libthr.so.3
#1  0x00000008009bdb69 in CRYPTO_THREAD_read_lock () from /lib/libcrypto.so.30
#2  0x00000008009ac2bf in ?? () from /lib/libcrypto.so.30
#3  0x00000008009bc773 in ?? () from /lib/libcrypto.so.30
#4  0x00000008009abf52 in OSSL_LIB_CTX_free () from /lib/libcrypto.so.30
#5  0x000000080116f2c6 in ?? () from /usr/lib/ossl-modules/legacy.so
#6  0x00000008009ba35d in ?? () from /lib/libcrypto.so.30
#7  0x0000000800b00420 in EVP_CIPHER_free () from /lib/libcrypto.so.30
#8  0x00000008007b9b2a in SSL_CTX_free () from /usr/lib/libssl.so.30
#9  0x000000000059f238 in ?? ()
#10 0x0000000000594b63 in ?? ()
#11 0x000000000055f243 in ?? ()
#12 0x0000000000556cea in ?? ()
#13 0x000000000055adca in Curl_conn_close ()
#14 0x00000000005ad0f6 in Curl_cshutdn_terminate ()
#15 0x00000000005ad620 in Curl_cshutdn_destroy ()
#16 0x0000000000577372 in curl_multi_cleanup ()
#17 0x0000000000551f7b in curl_cleanup ()
#18 0x0000000000519584 in ?? ()
#19 0x0000000000519463 in pkg_shutdown ()
#20 0x0000000800e16ec4 in __cxa_finalize () from /lib/libc.so.7
#21 0x0000000800e1746c in exit () from /lib/libc.so.7
#22 0x0000000800d36e3b in __libc_start1 () from /lib/libc.so.7
#23 0x0000000000312484 in _start ()


Hope this helps

-- 
You are receiving this mail because:
You are the assignee for the bug.