[arch-dev-public] [signoff] 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
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
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.
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.
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
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.
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
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.
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
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?
On Thu, Oct 06, 2011 at 05:44:54PM +0200, Thomas Bächler wrote:
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?
Not really. Life's been a bit busy with a job transition currently happening and a sudden strong desire to jump out of planes [0]. Recent free time went to pushing out a mkinitcpio release. I'll probably have a chance to poke around this weekend as I have some downtime on Saturday. I'm inclined to move in the direction of what Fedora does [1], which is to pull directly from mozilla NSS. That would at least take care of the bundle that we rely on for curl and wget. I'm left wondering where they get their loose certificates from, though, as they aren't included in their ca-certificates package [2]. d [0] http://i.imgur.com/YX9fp.jpg [1] http://pkgs.fedoraproject.org/gitweb/?p=ca-certificates.git [2] https://admin.fedoraproject.org/pkgdb/builds/show/F-devel-x86_64/ca-certific...
participants (4)
-
Dave Reisner
-
Jan de Groot
-
Stéphane Gaudreault
-
Thomas Bächler