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

Reply via email to