curl and certificate verification in jessie

[Jonathan Nieder]

reassign 771170 libcurl3-gnutls 7.38.0-3
affects 771170 + git
quit

Hi,

In November, 2014, Peter Palfrader wrote:

> I recently started to move parts of debian.org's infrastructure to jessie.  I
> noticed a regression with software using curl to do https with certificate
> verification.
>
> On wheezy, this works:
>
> | weasel at mipsel-manda-01:~$ cat /etc/apt/apt.conf.d/puppet-https-buildd
> | Acquire::https::buildd.debian.org::CaInfo "/etc/ssl/servicecerts/buildd.debian.org.crt";
> | weasel at mipsel-manda-01:~$ tail -n1 /etc/apt/sources.list.d/buildd.debian.org.list
> | deb     https://buildd.debian.org/apt/  wheezy  main
>
> I.e., I can use a local copy of the expected end-entity certificate to
> authenticate a https server.
>
> On jessie this no longer works:
>
> } Err https://buildd.debian.org wheezy/main mipsel Packages
> }   server certificate verification failed. CAfile: /etc/ssl/servicecerts/buildd.debian.org.crt CRLfile: none
>
> Instead, I have to trust the corresponding root certificate or an
>  intermediate (#771404).
>
> I noticed a similar issue with git, where using the EE-certificate or an
> intermediate as http.sslCAInfo fails to authenticate the server (#771170).
[...]
> I suspect that other users of curl/gnutls might be affected as well, and that
> saying "I only trust this exact certificate" is not a crazy and rare use-case.
> Thus, I'd like to learn more here and ideally have this resolved for jessie.

As you may have guessed, Git relies on libcurl for its certificate
checking, so moving to that package for triage.  This is most likely
related to gnutls, not libcurl, but that seems as good a place as any
to try to produce a minimal testcase using gnutls-bin.

https://lists.debian.org/debian-devel/2014/11/msg01358.html says it is
due to the gnutls26 -> gnutls28 switch but describes a test case using
curl still.

https://lists.debian.org/debian-devel/2014/12/msg00030.html describes
a way that libcurl could provide this feature using modern gnutls.

https://lists.debian.org/debian-devel/2014/12/msg00129.html describes
a way that libgnutls could support this use case without libcurl
changes.

Do you experience the same issue still today?

Sorry I missed this when you first sent it.  Hopefully we can tie
this loose end (either by passing the request upstream or documenting
the change).

Sincerely,
Jonathan