** 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
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
