curl 7.22.0-2
 

Hi all,

I dropped a new curl in testing a few days ago with only one real
change. It now builds and uses its own cacert bundle which is dropped in
/etc/ssl/certs/ca-bundle.crt. This is similar to the ca-certificates
bundle, but taken directly from Mozilla and processed with an in tree
perl script.

With this, the ca-certificates dep is of course removed. I don't expect
any regressions, but please dig up your curl/https powered apps and make
sure they still work.

Please signoff both arches.

Regards,
Dave

curl 7.22.0-2
 

Le 27 Septembre 2011 08:37:41 Dave Reisner a écrit :
> Hi all,
>
> I dropped a new curl in testing a few days ago with only one real
> change. It now builds and uses its own cacert bundle which is dropped in
> /etc/ssl/certs/ca-bundle.crt. This is similar to the ca-certificates
> bundle, but taken directly from Mozilla and processed with an in tree
> perl script.
>
> With this, the ca-certificates dep is of course removed. I don't expect
> any regressions, but please dig up your curl/https powered apps and make
> sure they still work.
>
> Please signoff both arches.
>
> Regards,
> Dave

Signoff i686.

Stéphane

curl 7.22.0-2
 

On di, 2011-09-27 at 08:37 -0400, Dave Reisner wrote:
> Hi all,
>
> I dropped a new curl in testing a few days ago with only one real
> change. It now builds and uses its own cacert bundle which is dropped in
> /etc/ssl/certs/ca-bundle.crt. This is similar to the ca-certificates
> bundle, but taken directly from Mozilla and processed with an in tree
> perl script.
>
> With this, the ca-certificates dep is of course removed. I don't expect
> any regressions, but please dig up your curl/https powered apps and make
> sure they still work.

What's the purpose of this? The whole reasoning behind ca-certificates
is to have a central certificate store. Remember that the
ca-certificates package as maintained by debian originates from NSS, so
basically these contain the same certificates.

IMHO this is a big -1 from my side.

curl 7.22.0-2
 

Am 27.09.2011 23:30, schrieb Jan de Groot:
>> I dropped a new curl in testing a few days ago with only one real
>> change. It now builds and uses its own cacert bundle which is dropped in
>> /etc/ssl/certs/ca-bundle.crt. This is similar to the ca-certificates
>> bundle, but taken directly from Mozilla and processed with an in tree
>> perl script.
>>
>> With this, the ca-certificates dep is of course removed. I don't expect
>> any regressions, but please dig up your curl/https powered apps and make
>> sure they still work.
>
> What's the purpose of this? The whole reasoning behind ca-certificates
> is to have a central certificate store. Remember that the
> ca-certificates package as maintained by debian originates from NSS, so
> basically these contain the same certificates.
>
> IMHO this is a big -1 from my side.

Agreed, without further explanation this seems like complete nonsense.

curl 7.22.0-2
 

On Wed, Sep 28, 2011 at 02:27:47PM +0200, Thomas Bächler wrote:
> Am 27.09.2011 23:30, schrieb Jan de Groot:
> >> I dropped a new curl in testing a few days ago with only one real
> >> change. It now builds and uses its own cacert bundle which is dropped in
> >> /etc/ssl/certs/ca-bundle.crt. This is similar to the ca-certificates
> >> bundle, but taken directly from Mozilla and processed with an in tree
> >> perl script.
> >>
> >> With this, the ca-certificates dep is of course removed. I don't expect
> >> any regressions, but please dig up your curl/https powered apps and make
> >> sure they still work.
> >
> > What's the purpose of this? The whole reasoning behind ca-certificates
> > is to have a central certificate store. Remember that the
> > ca-certificates package as maintained by debian originates from NSS, so
> > basically these contain the same certificates.
> >
> > IMHO this is a big -1 from my side.
>
> Agreed, without further explanation this seems like complete nonsense.
>

Well, you're both probably right and this should be fixed in
ca-certificates. As it currently stands with curl using ca-bundle.crt
versus wget using ca-certificate.crt....

$ wget --spider https://signin.ebay.com
Spider mode enabled. Check if remote file exists.
--2011-09-28 08:36:03-- https://signin.ebay.com/
Resolving signin.ebay.com... 66.211.181.96, 66.135.202.140, 66.135.205.10
Connecting to signin.ebay.com|66.211.181.96|:443... connected.
ERROR: cannot verify signin.ebay.com's certificate, issued by
`/C=US/O=VeriSign, Inc./OU=VeriSign Trust Network/OU=Terms of use at
https://www.verisign.com/rpa (c)06/CN=VeriSign Class 3 Extended
Validation SSL CA':
Unable to locally verify the issuer's authority. To connect to
signin.ebay.com insecurely, use `--no-check-certificate'.

$ curl -I https://signin.ebay.com
HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
ETag: W/"354-1117144930000"
Last-Modified: Thu, 26 May 2005 22:02:10 GMT
Content-Type: text/html
Content-Length: 354

So we're missing the VeriSign Class 3 cert which seems extremely odd.
As per Verisign[1], all class 3 root certs are in valid and should
remain in root certificate bundles.

I'd love to do a comparison and find out what else is missing from the
debian sourced bundle, but there's no comments in the ca-certificates
file which makes that job a bit more difficult.

dave

[1] http://www.verisign.com/support/roots.html

curl 7.22.0-2
 

Am 28.09.2011 14:52, schrieb Dave Reisner:
>>> What's the purpose of this? The whole reasoning behind ca-certificates
>>> is to have a central certificate store. Remember that the
>>> ca-certificates package as maintained by debian originates from NSS, so
>>> basically these contain the same certificates.
>>>
>>> IMHO this is a big -1 from my side.
>>
>> Agreed, without further explanation this seems like complete nonsense.
>>
>
> Well, you're both probably right and this should be fixed in
> ca-certificates. As it currently stands with curl using ca-bundle.crt
> versus wget using ca-certificate.crt....

Well then, we know what we should actually fix, as your "fix" will only
fix curl, but not wget and others.

curl 7.22.0-2
 

On Wed, Sep 28, 2011 at 04:01:01PM +0200, Thomas Bächler wrote:
> Am 28.09.2011 14:52, schrieb Dave Reisner:
> >>> What's the purpose of this? The whole reasoning behind ca-certificates
> >>> is to have a central certificate store. Remember that the
> >>> ca-certificates package as maintained by debian originates from NSS, so
> >>> basically these contain the same certificates.
> >>>
> >>> IMHO this is a big -1 from my side.
> >>
> >> Agreed, without further explanation this seems like complete nonsense.
> >>
> >
> > Well, you're both probably right and this should be fixed in
> > ca-certificates. As it currently stands with curl using ca-bundle.crt
> > versus wget using ca-certificate.crt....
>
> Well then, we know what we should actually fix, as your "fix" will only
> fix curl, but not wget and others.
>

Sure. Until I, or someone else, has time to look into it, I'm leaving
this in testing since curl is a dependency of over 100 packages.

https://bugs.archlinux.org/task/26135

dave

curl 7.22.0-2
 

On Wed, 2011-09-28 at 08:52 -0400, Dave Reisner wrote:
> So we're missing the VeriSign Class 3 cert which seems extremely odd.
> As per Verisign[1], all class 3 root certs are in valid and should
> remain in root certificate bundles.

We're not missing it in ca-certificates, we just have a different one.
Both ca-bundle.crt and ca-certificates.crt contain the same serial
number for this certificate, the only difference I can find is this:

Signature Algorithm: sha1WithRSAEncryption
Signature Algorithm: md2WithRSAEncryption

curl uses GNUTLS, which doesn't support MD2. OpenSSL should support it,
but it's deprecated. Our builds should still support md2, but I don't
know how far the application has to go to support it.

Our ca-certificates package contains these CAs that are not in mozilla
NSS:
- brasil.gov.br
- cacert.org
- debconf.org
- gouv.fr
- signet.pl
- spi-inc.org

We patch cacert.org and spi-inc.org into NSS, so that narrows the list a
bit. IMHO we should just drop ca-certificates in its current shape and
replace it with a dump from our NSS package. We could even discuss about
the inclusion of spi-inc.org and cacert certificates.

curl 7.22.0-2
 

On Wed, Sep 28, 2011 at 04:39:20PM +0200, Jan de Groot wrote:
> On Wed, 2011-09-28 at 08:52 -0400, Dave Reisner wrote:
> > So we're missing the VeriSign Class 3 cert which seems extremely odd.
> > As per Verisign[1], all class 3 root certs are in valid and should
> > remain in root certificate bundles.
>
> We're not missing it in ca-certificates, we just have a different one.
> Both ca-bundle.crt and ca-certificates.crt contain the same serial
> number for this certificate, the only difference I can find is this:
>
> Signature Algorithm: sha1WithRSAEncryption
> Signature Algorithm: md2WithRSAEncryption
>
> curl uses GNUTLS, which doesn't support MD2. OpenSSL should support it,

Our curl does not link against gnutls. Upstream doesn't recommend this,
either, when openssl is available.

> know how far the application has to go to support it.
>
> Our ca-certificates package contains these CAs that are not in mozilla
> NSS:
> - brasil.gov.br
wget can't verify this cert.

> - debconf.org
wget can't verify this cert.

> - signet.pl
wget can't verify this cert. The common name is
www.bptp.lodz.telekomunikacja.pl, but wget won't verify that either.

> We patch cacert.org and spi-inc.org into NSS, so that narrows the list a
> bit. IMHO we should just drop ca-certificates in its current shape and
> replace it with a dump from our NSS package. We could even discuss about
> the inclusion of spi-inc.org and cacert certificates.

Sure, I'm very interested in doing this. The current certs package is
pretty ugly. Unfortunately, every distro seems to have their own method
of managing this.

d

curl 7.22.0-2
 

Am 28.09.2011 17:01, schrieb Dave Reisner:
>> We patch cacert.org and spi-inc.org into NSS, so that narrows the list a
>> bit. IMHO we should just drop ca-certificates in its current shape and
>> replace it with a dump from our NSS package. We could even discuss about
>> the inclusion of spi-inc.org and cacert certificates.
>
> Sure, I'm very interested in doing this. The current certs package is
> pretty ugly. Unfortunately, every distro seems to have their own method
> of managing this.

Did you make any progress on this?