[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
This bug was fixed in the package curl - 7.88.1-8ubuntu2
---
curl (7.88.1-8ubuntu2) lunar; urgency=medium
* d/p/Use-correct-path-when-loading-libnss-pem-ckbi-.so.patch:
Don't prepend "nss" when opening libnssckbi.so. Rename definition
to _DEB_TARGET_ARCH. (LP: #2016439)
* d/rules: Declare DEB_TARGET_MULTIARCH. Rename definition to
_DEB_TARGET_ARCH.
-- Sergio Durigan Junior Thu, 20 Apr
2023 17:30:44 -0400
** Changed in: curl (Ubuntu Lunar)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
Fix Released
Status in curl source package in Lunar:
Fix Released
Status in curl source package in Mantic:
Fix Released
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list:
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
I just checked and a rebuild of the test app is not necessary, which is
good, otherwise we would have to chase down anything in the archive that
linked with the libcurl3-nss library package and rebuild those.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
Fix Released
Status in curl source package in Lunar:
Fix Released
Status in curl source package in Mantic:
Fix Released
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
All dep8 failures have been resolved.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
Fix Released
Status in curl source package in Lunar:
Fix Committed
Status in curl source package in Mantic:
Fix Released
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
Verifying the bug for Lunar. First, make sure we can reproduce the problem. After following the steps outlined in the Test Plan, we see: # ./curl-test curl_easy_perform() failed: SSL peer certificate or SSH remote key was not OK # apt policy libcurl4-nss-dev libcurl4-nss-dev: Installed: 7.88.1-8ubuntu1 Candidate: 7.88.1-8ubuntu1 Version table: *** 7.88.1-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu lunar/universe amd64 Packages 100 /var/lib/dpkg/status Now, install libcurl4-nss-dev from -proposed and verify that the new package fixes the issue: # apt policy libcurl4-nss-dev libcurl4-nss-dev: Installed: 7.88.1-8ubuntu2 Candidate: 7.88.1-8ubuntu2 Version table: *** 7.88.1-8ubuntu2 400 400 http://archive.ubuntu.com/ubuntu lunar-proposed/universe amd64 Packages 100 /var/lib/dpkg/status 7.88.1-8ubuntu1 500 500 http://archive.ubuntu.com/ubuntu lunar/universe amd64 Packages # gcc curl-test.c -o curl-test -lcurl # ./curl-test Example Domain
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
Thanks for the review and for accepting the SRU, Andreas.
The bug can be considered fixed in Mantic, although the change present
there is not exactly the same as the one I uploaded to Lunar (it still
uses $(DEB_HOST_ARCH) instead of $(DEB_TARGET_ARCH), and it
unnecessarily patches the load path for libnssckbi.so).
I'm a bit weary of introducing another delta to the package only to
address these minor details, so I will instead upload a small change to
the patch in Debian and later merge it into Mantic.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
Fix Released
Status in curl source package in Lunar:
Fix Committed
Status in curl source package in Mantic:
Fix Released
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list:
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
Thanks for the new upload. Please also fix this in mantic, either via a
mantic upload with the same change, or a debian change/upload and later
re-merge in mantic.
** Changed in: curl (Ubuntu Lunar)
Status: In Progress => Fix Committed
** Tags added: verification-needed verification-needed-lunar
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
In Progress
Status in curl source package in Lunar:
Fix Committed
Status in curl source package in Mantic:
In Progress
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
** Also affects: curl (Ubuntu Mantic)
Importance: High
Assignee: Sergio Durigan Junior (sergiodj)
Status: In Progress
** Also affects: curl (Ubuntu Lunar)
Importance: Undecided
Status: New
** Changed in: curl (Ubuntu Lunar)
Assignee: (unassigned) => Sergio Durigan Junior (sergiodj)
** Changed in: curl (Ubuntu Lunar)
Importance: Undecided => High
** Changed in: curl (Ubuntu Lunar)
Status: New => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
In Progress
Status in curl source package in Lunar:
In Progress
Status in curl source package in Mantic:
In Progress
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to :
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
We talked about it and agreed on the following changes:
- don't patch the libnssckbi.so library path anymore, as that one is working in
the original code
- for libnsspem.so, use a debian architecture macro that respects cross
compiles and uses the target arch instead of the host one.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
In Progress
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
"'
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
As I understand it, libnsspem.so is the one in the "wrong" place:
/usr/lib/$ARCH/nss/libnsspem.so
A quick apt-file search on lunar shows that is the only package that
puts something in /usr/lib/$ARCH/nss.
I appended this config to my ~/.pki/nssdb/pkcs11.txt file to test search
paths:
library=libnsspem.so
name=PEM_plugin
And ran this test command with strace:
certutil -d ~/.pki/nssdb -U
It shows the search path for the library:
143458 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnsspem.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
143458 openat(AT_FDCWD, "/usr/lib/x86_64-linux-gnu/libnsspem.so",
O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
143458 openat(AT_FDCWD, "/lib/libnsspem.so", O_RDONLY|O_CLOEXEC) = -1 ENOENT
(No such file or directory)
143458 openat(AT_FDCWD, "/usr/lib/libnsspem.so", O_RDONLY|O_CLOEXEC) = -1
ENOENT (No such file or directory)
So yes, /usr/lib/$ARCH/nss is not searched for. Which means it's an odd
placement choice decision from the src:nss-pem package. Or maybe src:nss
should include that nss/ subdirectory in its search path.
In any case, back to the current bug.
It looks like a minimal patch would be to leave libnssckbi.so alone, as
that will be found in the standard paths if I define it without an
absolute path in pkcs11.txt:
library=libnssckbi.so
name=Mozilla Root Certs
NSS=trustOrder=100
And strace:
143993 openat(AT_FDCWD, "/lib/x86_64-linux-gnu/libnssckbi.so",
O_RDONLY|O_CLOEXEC) = 7
So how about just patching the libnsspem.so path? And reverting the change to
the
`static const char *trust_library` path all the way back so it's just
"libnssckbi.so"?
On a second note, has this been tested in other architectures, to be
sure the _DEB_HOST_ARCH replacement is correct there as well? I'm
thinking ppc64el vs ppc64le, for example, and whether the linux-gnu
suffix is always used correctly.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
In Progress
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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
Example Domain
...
#
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
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
** Description changed:
[ 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.
+ 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
+ #include
+
+ 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
+
+
+
+ Example Domain
+ ...
+ #
+
+ 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
"'
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to curl in Ubuntu.
https://bugs.launchpad.net/bugs/2016439
Title:
Regression finding system certificates
Status in curl package in Ubuntu:
In Progress
Status in curl package in Debian:
Fix Released
Bug 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 ]
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
#include
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,
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
** Description changed: + [ 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. + * 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 + --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 " + 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 "' ** Changed in: curl (Ubuntu) Status: Triaged => In Progress -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/2016439 Title: Regression finding system certificates Status in curl package in Ubuntu: In Progress Status in curl package in Debian: Fix Released Bug 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
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
** Tags added: server-todo -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/2016439 Title: Regression finding system certificates Status in curl package in Ubuntu: Triaged Status in curl package in Debian: Fix Released Bug 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 "' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
** Changed in: curl (Debian) Status: Unknown => Fix Released -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/2016439 Title: Regression finding system certificates Status in curl package in Ubuntu: Triaged Status in curl package in Debian: Fix Released Bug 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 "' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 2016439] Re: Regression finding system certificates
** Bug watch added: Debian Bug tracker #1034359 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 ** Also affects: curl (Debian) via https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1034359 Importance: Unknown Status: Unknown -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to curl in Ubuntu. https://bugs.launchpad.net/bugs/2016439 Title: Regression finding system certificates Status in curl package in Ubuntu: Triaged Status in curl package in Debian: Fix Released Bug 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 "' To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/curl/+bug/2016439/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
