| 2023-04-16 23:04:43 |
Sergio Durigan Junior |
bug |
|
|
added bug |
| 2023-04-17 20:13:22 |
Sergio Durigan Junior |
bug watch added |
|
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 |
|
| 2023-04-17 20:13:22 |
Sergio Durigan Junior |
bug task added |
|
curl (Debian) |
|
| 2023-04-17 20:18:57 |
Bug Watch Updater |
curl (Debian): status |
Unknown |
Fix Released |
|
| 2023-04-19 14:58:06 |
Sergio Durigan Junior |
tags |
|
server-todo |
|
| 2023-04-19 14:58:15 |
Sergio Durigan Junior |
bug |
|
|
added subscriber Ubuntu Server |
| 2023-04-19 18:57:43 |
Sergio Durigan Junior |
description |
[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]
Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:
curl (7.88.1-4) unstable; urgency=medium
* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.
Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.
libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.
Here is a way to test the regression:
debbisect -v --cache=./cache \
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"' |
[ Impact ]
Users of applications that link against libcurl's NSS flavour might experience issues when trying to contact HTTPS servers. This can lead to scenarios where the application is unable to connect.
[ Test Plan ]
TBD.
[ Where problems could occur ]
The adjustment needed to the downstream patch is pretty simple and has been tested extensively. The original reporter mentioned that the issue did not happen before this patch was applied, so in the unlikely event of a regression the best route would be to revert the patch entirely.
[ More Info ]
This happens because of an error in one of our patches (authored by me) to teach libcurl where to properly find libnsspem.so and libnssckbi.so. The problem is that libnsspem.so is installed under /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look under the "/nss/" directory for both libraries. As it turns out, libnssckbi.so is necessary in order to use the Mozilla's root certificate.
[ Original Description ]
[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]
Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:
curl (7.88.1-4) unstable; urgency=medium
* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.
Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.
libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.
Here is a way to test the regression:
debbisect -v --cache=./cache \
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"' |
|
| 2023-04-19 18:57:57 |
Sergio Durigan Junior |
curl (Ubuntu): status |
Triaged |
In Progress |
|
| 2023-04-19 19:07:18 |
Sergio Durigan Junior |
description |
[ Impact ]
Users of applications that link against libcurl's NSS flavour might experience issues when trying to contact HTTPS servers. This can lead to scenarios where the application is unable to connect.
[ Test Plan ]
TBD.
[ Where problems could occur ]
The adjustment needed to the downstream patch is pretty simple and has been tested extensively. The original reporter mentioned that the issue did not happen before this patch was applied, so in the unlikely event of a regression the best route would be to revert the patch entirely.
[ More Info ]
This happens because of an error in one of our patches (authored by me) to teach libcurl where to properly find libnsspem.so and libnssckbi.so. The problem is that libnsspem.so is installed under /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look under the "/nss/" directory for both libraries. As it turns out, libnssckbi.so is necessary in order to use the Mozilla's root certificate.
[ Original Description ]
[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]
Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:
curl (7.88.1-4) unstable; urgency=medium
* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.
Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.
libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.
Here is a way to test the regression:
debbisect -v --cache=./cache \
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"' |
[ Impact ]
Users of applications that link against libcurl's NSS flavour might experience issues when trying to contact HTTPS servers. This can lead to scenarios where the application is unable to connect.
[ Test Plan ]
First, let's verify that the GNUTLS flavour of libcurl does the right thing:
$ lxc launch ubuntu-daily:lunar curl-bug2016439
$ lxc shell curl-bug2016439
# apt update && apt install -y libcurl4-gnutls-dev gcc
# cat > curl-test.c << __EOF__
#include <stdio.h>
#include <curl/curl.h>
int main(void)
{
CURL *curl;
CURLcode res;
curl = curl_easy_init();
if(curl) {
curl_easy_setopt(curl, CURLOPT_URL, "https://example.com");
/* example.com is redirected, so we tell libcurl to follow redirection */
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1L);
/* Perform the request, res will get the return code */
res = curl_easy_perform(curl);
/* Check for errors */
if(res != CURLE_OK)
fprintf(stderr, "curl_easy_perform() failed: %s\n",
curl_easy_strerror(res));
/* always cleanup */
curl_easy_cleanup(curl);
}
return 0;
}
__EOF__
# gcc curl-test.c -o curl-test -lcurl
# ./curl-test
<!doctype html>
<html>
<head>
<title>Example Domain</title>
...
#
You should see the HTML dump of example.com. Now, let's install the NSS flavour of libcurl and recompile the test program against it:
# apt install -y libcurl4-nss-dev
# gcc curl-test.c -o curl-test -lcurl
# ./curl-test
curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK
As we can see, there was an error when validating the TLS certificate.
[ Where problems could occur ]
The adjustment needed to the downstream patch is pretty simple and has been tested extensively. The original reporter mentioned that the issue did not happen before this patch was applied, so in the unlikely event of a regression the best route would be to revert the patch entirely.
[ More Info ]
This happens because of an error in one of our patches (authored by me) to teach libcurl where to properly find libnsspem.so and libnssckbi.so. The problem is that libnsspem.so is installed under /usr/lib/$(DEB_HOST_ARCH)/nss/, while libnssckbi.so is installed under /usr/lib/$(DEB_HOST_ARCH)/, but I mistakenly pointed libcurl to look under the "/nss/" directory for both libraries. As it turns out, libnssckbi.so is necessary in order to use the Mozilla's root certificate.
[ Original Description ]
[ Clone of https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ]
Between 7.88.1-2 and 7.88.1-5, there was a change to where curl with
nss looks for loadable libraries:
curl (7.88.1-4) unstable; urgency=medium
* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Prepend "/nss/" before the library name.
Before the change to the load path, curl could find
/lib/x86_64-linux-gnu/libnssckbi.so but not
/lib/x86_64-linux-gnu/nss/libnsspem.so, after the change it's the
reverse.
libnssckbi.so is enough to get a trust root (the mozilla certificate
store is compiled inside that library), whereas libnsspem.so
(1.0.8+1-1) isn't.
This makes it impossible to connect to https servers by default for
programs that use curl with NSS.
Here is a way to test the regression:
debbisect -v --cache=./cache \
--depends=libcurl4-nss-dev,git,pkg-config,libssl-dev,ca-certificates,cargo,nss-plugin-pem,p11-kit-modules,strace
\
20230306T145638Z 20230306T203828Z \
'chroot "$1" bash -exuc "
git clone --depth 1 https://github.com/alexcrichton/curl-rust.git
cd curl-rust
time cargo fetch
time cargo build --offline --example https
strace -efile target/debug/examples/https >/dev/null
"' |
|
| 2023-04-20 19:54:46 |
Andreas Hasenack |
bug |
|
|
added subscriber Andreas Hasenack |
| 2023-05-12 12:47:46 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-05-12 12:47:46 |
Andreas Hasenack |
bug task added |
|
curl (Ubuntu Mantic) |
|
| 2023-05-12 12:47:46 |
Andreas Hasenack |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-05-12 12:47:46 |
Andreas Hasenack |
bug task added |
|
curl (Ubuntu Lunar) |
|
| 2023-05-12 12:48:00 |
Andreas Hasenack |
curl (Ubuntu Lunar): assignee |
|
Sergio Durigan Junior (sergiodj) |
|
| 2023-05-12 12:48:03 |
Andreas Hasenack |
curl (Ubuntu Lunar): importance |
Undecided |
High |
|
| 2023-05-12 12:48:05 |
Andreas Hasenack |
curl (Ubuntu Lunar): status |
New |
In Progress |
|
| 2023-05-12 13:10:07 |
Andreas Hasenack |
curl (Ubuntu Lunar): status |
In Progress |
Fix Committed |
|
| 2023-05-12 13:10:08 |
Andreas Hasenack |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2023-05-12 13:10:14 |
Andreas Hasenack |
bug |
|
|
added subscriber SRU Verification |
| 2023-05-12 13:10:20 |
Andreas Hasenack |
tags |
server-todo |
server-todo verification-needed verification-needed-lunar |
|
| 2023-05-12 21:15:58 |
Sergio Durigan Junior |
tags |
server-todo verification-needed verification-needed-lunar |
server-todo verification-done verification-done-lunar |
|
| 2023-05-12 21:16:38 |
Sergio Durigan Junior |
curl (Ubuntu Mantic): status |
In Progress |
Fix Released |
|
| 2023-05-25 19:38:31 |
Launchpad Janitor |
curl (Ubuntu Lunar): status |
Fix Committed |
Fix Released |
|
| 2023-05-25 19:38:37 |
Andreas Hasenack |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
