Hello Sergio, or anyone else affected, Accepted curl into lunar-proposed. The package will build now and be available at https://launchpad.net/ubuntu/+source/curl/7.88.1-8ubuntu2 in a few hours, and then in the -proposed repository.
Please help us by testing this new package. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how to enable and use -proposed. Your feedback will aid us getting this update out to other Ubuntu users. If this package fixes the bug for you, please add a comment to this bug, mentioning the version of the package you tested, what testing has been performed on the package and change the tag from verification-needed- lunar to verification-done-lunar. If it does not fix the bug for you, please add a comment stating that, and change the tag to verification- failed-lunar. In either case, without details of your testing we will not be able to proceed. Further information regarding the verification process can be found at https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in advance for helping! N.B. The updated package will be released to -updates after the bug(s) fixed by this package have been verified and the package has been in -proposed for a minimum of 7 days. -- 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 <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 "' 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
