Debian Bug report logs - #858539
ca-certificates: Contains untrusted StartCom and WoSign certificates

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: submit@bugs.debian.org

Subject: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Thu, 23 Mar 2017 09:02:34 +0000

Package: ca-certificates
Version: 20141019+deb8u2
Severity: important
Tags: security

Hi,

StartCom and WoSign certificates are now untrusted by the major browser
vendors[0][1], making websites that use certs from these vendors
inaccessible.

However, as this is not reflected in ca-certificates, tools such as curl
still intepret these as valid/secure.

(This has a knock-on effect that health-check tools that use the output
of such tools to determine whether a site is "up" — eg. updown.io — will
misleadingly imply that the site is available to users when, in all
practical senses, they are not.)

I would suggest we remove the offending authorities from ca-certificates
as soon as possible.


[0] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
[1] My installation "chrome-stable" rejects them as well.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #10 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Chris Lamb <lamby@debian.org>, 858539@bugs.debian.org

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Thu, 23 Mar 2017 09:25:42 -0500

On 03/23/2017 04:02 AM, Chris Lamb wrote:
> StartCom and WoSign certificates are now untrusted by the major browser
> vendors[0][1], making websites that use certs from these vendors
> inaccessible.

I followed these events on dev-security-policy and libnss performs date
checks on certs signed by these roots, which ca-certificates has no
facility to perform.

> However, as this is not reflected in ca-certificates, tools such as curl
> still intepret these as valid/secure.

Blacklisting StartCom and WoSign roots will possibly invalidate some
user's pre- Oct 21, 2016 valid certificates, but I think that is
probably OK.

> (This has a knock-on effect that health-check tools that use the output
> of such tools to determine whether a site is "up" — eg. updown.io — will
> misleadingly imply that the site is available to users when, in all
> practical senses, they are not.)
> 
> I would suggest we remove the offending authorities from ca-certificates
> as soon as possible.
> 
> 
> [0] https://blog.mozilla.org/security/2016/10/24/distrusting-new-wosign-and-startcom-certificates/
> [1] My installation "chrome-stable" rejects them as well.

Thanks for the report, Chris.

-- 
Kind regards,
Michael

Message #15 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: Michael Shuler <michael@pbandjelly.org>, 858539@bugs.debian.org

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Thu, 23 Mar 2017 19:27:17 +0000

Michael Shuler wrote:

> libnss performs date checks on certs signed by these roots
[…]
> Blacklisting StartCom and WoSign roots will possibly invalidate some
> user's pre- Oct 21, 2016 valid certificates, but I think that is
> probably OK.

I agree :)


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #20 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@orangeseeds.org>

To: Michael Shuler <michael@pbandjelly.org>, 858539@bugs.debian.org

Cc: Chris Lamb <lamby@debian.org>

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Mon, 27 Mar 2017 10:39:17 -0400

[Message part 1 (text/plain, inline)]

On Thu, Mar 23, 2017 at 09:25:42AM -0500, Michael Shuler wrote:
> Thanks for the report, Chris.

Any timeline for this deployment? Do you need help with patching this
in?

A.

[signature.asc (application/pgp-signature, inline)]

Message #25 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: Antoine Beaupre <anarcat@orangeseeds.org>, Michael Shuler <michael@pbandjelly.org>, 858539@bugs.debian.org

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Mon, 27 Mar 2017 15:41:16 +0100

Antoine,

> Any timeline for this deployment?

Thu 23 09:12 < jmm_> next point release. along with the generic ca-cerficates refresh


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #30 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@orangeseeds.org>

To: Michael Shuler <michael@pbandjelly.org>, 858539@bugs.debian.org

Cc: Chris Lamb <lamby@debian.org>

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Mon, 27 Mar 2017 11:00:36 -0400

[Message part 1 (text/plain, inline)]

On Mon, Mar 27, 2017 at 10:39:17AM -0400, Antoine Beaupre wrote:
> On Thu, Mar 23, 2017 at 09:25:42AM -0500, Michael Shuler wrote:
> > Thanks for the report, Chris.
> 
> Any timeline for this deployment? Do you need help with patching this
> in?

Actually, I'm not sure I understand what's going on here. While Mozilla
announced they would stop trusting WoSign, they didn't actually remove
the trust roots from the store. Indeed, they said they "may choose to
remove them at any point after March 2017", which they haven't done yet.
WoSign and StartCom are still both here:

https://mozillacaprogram.secure.force.com/CA/CACertificatesInFirefoxReport

and here:

https://hg.mozilla.org/mozilla-central/raw-file/tip/security/nss/lib/ckfw/builtins/certdata.txt

... the latter seemingly being the source for our own certdata.txt.

That said, Mozilla should refuse certs issued after October 21, 2016,
something we can't do ourselves. So the patch would probably be to add
this to the blacklist.txt file:

"StartCom Certification Authority"
"StartCom Certification Authority"
"StartCom Certification Authority"
"StartCom Certification Authority"
"StartCom Certification Authority G2"
"StartCom Certification Authority G2"
"WoSign"
"WoSign"
"WoSign China"
"WoSign China"
"Certification Authority of WoSign G2"
"Certification Authority of WoSign G2"
"CA WoSign ECC Root"
"CA WoSign ECC Root"

This list was generated with:

    egrep 'WoSign|StartCom' mozilla/certdata.txt  | grep UTF | sed 's/CKA_LABEL UTF8 //'

I hope that helps!

A.

[signature.asc (application/pgp-signature, inline)]

Message #37 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 858539@bugs.debian.org

Subject: Re: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Thu, 04 May 2017 16:31:22 +0100

severity 858539 serious
thanks


We should not release stretch with these certificates; not only would
it be embarrassing to do so given that they have ceased to work in
modern browsers for some time, we are also simply putting our users
at risk.

Whilst there will be more CA screwups in the future, we should release
with our reasonable best effort, which surely means "just" removing
these.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

Message #44 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 858539@bugs.debian.org

Cc: control@bugs.debian.org

Subject: Re: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Fri, 19 May 2017 16:07:31 +0100

[Message part 1 (text/plain, inline)]

tags 858539 + pending patch
thanks

I've uploaded ca-certificates 20161130+nmu1 to DELAYED/5:
  
  ca-certificates (20161130+nmu1) unstable; urgency=medium
  
    * Non-maintainer upload.
    * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they are
      now untrusted by the major browser vendors. Closes: #858539

The full debdiff is attached.


Regards,

-- 
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      lamby@debian.org / chris-lamb.co.uk
       `-

[ca-certificates_20161130+nmu1_amd64.debdiff.txt (text/plain, attachment)]

Message #51 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Chris Lamb <lamby@debian.org>

Cc: 858539@bugs.debian.org

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Fri, 19 May 2017 10:46:35 -0500

[Message part 1 (text/plain, inline)]

On 05/19/2017 10:07 AM, Chris Lamb wrote:
> I've uploaded ca-certificates 20161130+nmu1 to DELAYED/5:
>   
>   ca-certificates (20161130+nmu1) unstable; urgency=medium
>   
>     * Non-maintainer upload.
>     * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they are
>       now untrusted by the major browser vendors. Closes: #858539

Thank you for the NMU, Chris, I'm good with that change.

-- 
Kind regards,
Michael

[signature.asc (application/pgp-signature, attachment)]

Message #56 received at 858539-close@bugs.debian.org (full text, mbox, reply):

From: Chris Lamb <lamby@debian.org>

To: 858539-close@bugs.debian.org

Subject: Bug#858539: fixed in ca-certificates 20161130+nmu1

Date: Wed, 24 May 2017 15:48:45 +0000

Source: ca-certificates
Source-Version: 20161130+nmu1

We believe that the bug you reported is fixed in the latest version of
ca-certificates, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 858539@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Chris Lamb <lamby@debian.org> (supplier of updated ca-certificates package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Format: 1.8
Date: Fri, 19 May 2017 16:53:16 +0200
Source: ca-certificates
Binary: ca-certificates ca-certificates-udeb
Architecture: source all
Version: 20161130+nmu1
Distribution: unstable
Urgency: medium
Maintainer: Michael Shuler <michael@pbandjelly.org>
Changed-By: Chris Lamb <lamby@debian.org>
Description:
 ca-certificates - Common CA certificates
 ca-certificates-udeb - Common CA certificates - udeb (udeb)
Closes: 858539
Changes:
 ca-certificates (20161130+nmu1) unstable; urgency=medium
 .
   * Non-maintainer upload.
   * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they are
     now untrusted by the major browser vendors. Closes: #858539
Checksums-Sha1:
 f599c3a2a1610db575840e0fb008ea7103184b8b 1886 ca-certificates_20161130+nmu1.dsc
 0a5f4cfde484de562c711044ec85ea7cdc54318d 298648 ca-certificates_20161130+nmu1.tar.xz
 ea4d034472615b20124b060c26b3f37d8e9d1025 151078 ca-certificates-udeb_20161130+nmu1_all.udeb
 eab87c1cfabf5da427365c2826432b684f62fec2 195794 ca-certificates_20161130+nmu1_all.deb
 861b048cfbc147e502aa1e026f6b75c6d8d2725d 6100 ca-certificates_20161130+nmu1_amd64.buildinfo
Checksums-Sha256:
 09e8d33c479827b070719170a9a98de7c1d4e9c7973ed8556321d08d8ae27494 1886 ca-certificates_20161130+nmu1.dsc
 77f9aca431e3122bf04aa0ffd989b723d906db4d1c106e3290e463d73c177f0e 298648 ca-certificates_20161130+nmu1.tar.xz
 9643f55c0eeac414155340aa553e12b4f3a9c080f5226af9ebc886cb712698df 151078 ca-certificates-udeb_20161130+nmu1_all.udeb
 25d6f749c4fb33ae0d7999c2c7c52b842a8b6e5487f3a5c1e61b3c21f90ac452 195794 ca-certificates_20161130+nmu1_all.deb
 d6a346c124f7415d2dc61ea4f62657265a2af9c4cbcffe8982b39c57c00250ed 6100 ca-certificates_20161130+nmu1_amd64.buildinfo
Files:
 50d47199c79c936633e4048edf410c66 1886 misc optional ca-certificates_20161130+nmu1.dsc
 a09e8b63126188fd0ed77f6fbaf5d35f 298648 misc optional ca-certificates_20161130+nmu1.tar.xz
 13def6a0b886d635d9c5f57973d486d3 151078 debian-installer optional ca-certificates-udeb_20161130+nmu1_all.udeb
 3eed7f5c0075abe44f932df597312af0 195794 misc optional ca-certificates_20161130+nmu1_all.deb
 66b2d6b55abfc28a19d29ae058ce771c 6100 misc optional ca-certificates_20161130+nmu1_amd64.buildinfo

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEwv5L0nHBObhsUz5GHpU+J9QxHlgFAlkfChsACgkQHpU+J9Qx
HlheZhAAlVidOHpgC/7UZAZnpaA5cIW7MS3Oorn4YvhVc9NUSMB7GDJsN2vULke4
dtLymLWT51KJhUyiIbMVzyH/ILqKThDcaQ6RtDXbJqVru33mMaTQOL6BK4+EygD8
FXODMrmHui71ZeD5pLX+pJ8bk8fuKNDoPDmy9Hxw1kL5gcVJgs1sDc5mX5+gp3Ro
emIEPamZpQzkkUxtJZXuJ9IeCIrCkCnWVhLam1EEkbir3UI8/y1OXetsJW4wlDwB
3PJdQz+BkIAA4iFXYpUakt6q1biSIpZ6ATpNMgaXcuJFwfQxgVt8orxcxwhFvN5C
h7GVLu3/XHBNioyjq8CrMhK68IeaU5Go1Xld7jNmQgAY/1tOMFDdjhwtoWCMmLah
oY0CEeCT8RBsPhD1d/rW/NdRi20kuWZmzjvuiQV/c2cSTteYmYLDQw9PnhJvrRP4
5KP7+1JgBfHvdUgLTOeSYloXwSiwR0eTsn/+Gk1X3UY7M0F06u9kYXZUIg5rE3o/
OvMMttswGWNZIP2wKlBxCt3ujaaLfl6XOZjdg7+Yv33vjO7NyPQSq1W4QUae/cpz
VYTnowN0/7sDwRNAqx0eG5TvBLplPvfpzcwky4TKjmCFEzs4FGSqPkstPknb2ud/
SQB8UXQcva/aR5zJVSqPa7cHOUaZgKtLPhKSsLVm93I4WQhaC2Q=
=gLdj
-----END PGP SIGNATURE-----

Message #61 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Bjarni Runar Einarsson <bre@pagekite.net>

To: 858539 <858539@bugs.debian.org>

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Fri, 02 Jun 2017 16:33:59 -0000

[Message part 1 (text/plain, inline)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hello folks,

I wanted to register a voice of dissent here. I don't think
"embarrassment" justifies breaking people's working and valid
certificates in this way.

This is only barely a security issue - StartCom and WoSign were
being punished for not following the rules.

The reduced trust in their their roots was not caused by any
actual user harm, it was a punitive measure to show the world
that certificate authorities cannot get away with flouting the
rules. All they did was fudge some dates to help their customers
work around issues caused by the forced SHA-1 deprecation. The
browser vendors recognized this and took special care to design
the punishment in a way that wouldn't break existing sites. That
is why there is a cut-off date involved.

Debian's participation in this is not necessary to punish these
vendors; the browsers have that well in hand! I have not seen any
explanation of why this is actually a security concern, as far as
I can tell, all Debian is accomplishing here is to hurt its own
users and innocent third parties.

I am one such party; this impacts me (and my users), because
pagekite (as packaged and shipped by Debian) is connecting to
servers that use an pre-cut-off TLS certificate, a certificate
that has no security issues. Due to complicating factors at my
end (a lot of my users are in an embedded environment where
updates are difficult), it is not easy for me to change
certificates. Others may be in the same boat; I think it's safe
to assume that anyone still using a StartCom cert is doing so
because their circumstance makes migration difficult.

Thanks for listening and thanks for your work on Debian,

 - Bjarni

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBCgAGBQJZMZOMAAoJEI4ANxYAz5SRsYcIAJM+hG7/7DCGUpG29z+wtqSt
PyX4e2nQTUnaySXYUpLlDSTYxxQVVaphm4uvY6FwsY27umxqlN7SvFrfylHiiSaV
LyKld7T2N/r0xAB3SfAMY0M3z/3WvADUUolHlsU6ju9RRwBAoNKqVRT/c9BPBsF5
CQW95MgGkMamIGeRgTL8uGBYBuZIEgK7ozHsthXu6jsh7DQWNuSngklTuDulEnhT
zlptlilwl3/9s19NMXmF07nc1b0YFfWtj+SDCZtW2LpyDxoHCOZRnwVkJl7odqag
uQ5ltV24VCuosGQRpaWr4q0PHXkLpbcnDUpPCpzcBSy3pyflPmEFMbGkXDWgZdA=
=B3aE
-----END PGP SIGNATURE-----

Message #66 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@orangeseeds.org>

To: Michael Shuler <michael@pbandjelly.org>, 858539@bugs.debian.org

Subject: Re: Bug#858539: ca-certificates: Contains untrusted StartCom and WoSign certificates

Date: Thu, 6 Jul 2017 13:37:29 -0400

[Message part 1 (text/plain, inline)]

On Fri, May 19, 2017 at 10:46:35AM -0500, Michael Shuler wrote:
> On 05/19/2017 10:07 AM, Chris Lamb wrote:
> > I've uploaded ca-certificates 20161130+nmu1 to DELAYED/5:
> >   
> >   ca-certificates (20161130+nmu1) unstable; urgency=medium
> >   
> >     * Non-maintainer upload.
> >     * Add StartCom and WoSign certificates to mozilla/blacklist.txt as they are
> >       now untrusted by the major browser vendors. Closes: #858539
> 
> Thank you for the NMU, Chris, I'm good with that change.

Do you plan on making a similar update to oldstable (jessie)?

By the way, I see the 2.11 update to unstable is still pending, but I
have managed to merge in the above NMU in the git repository and pushed
it to collab-maint.

https://anonscm.debian.org/git/collab-maint/ca-certificates.git/commit/?id=c5f9e62eb3a307ccb3d581dba7c38d19b6a5ba87

Is there something blocking that 2.11 upload?

I have also prepared an upload for jessie and wheezy that would fix this
bug, attached. I wonder, however, what the correct course of action is
considering that you have that 2.11 update pending - shouldn't we just
trickle down certdata.txt down into all suites?

Let me know how we should process this,

A.

[0001-merge-in-NMU-for-858539-jessie.patch (text/x-diff, attachment)]

[0001-merge-in-NMU-for-858539-wheezy.patch (text/x-diff, attachment)]

[signature.asc (application/pgp-signature, inline)]

Message #71 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org

Cc: debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: should ca-certificates certdata.txt synchronize across all suites?

Date: Thu, 06 Jul 2017 14:01:23 -0400

Hi everyone,

In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
wheezy, I noticed the issue was also pending in jessie. Furthermore, the
idea originally raised by pabs[1] was to also update the packages for
the latest changes in certdata.txt in wheezy, including the ISRG Root
for Let's Encrypt (LE).

While it should be fairly trivial to do this update, I wonder if the
same logic should apply to jessie itself. Right now, jessie and stretch
are synchronized, but that's only because there's an update pending in
unstable to synchronize with the upstream 2.11 NSS database.

This raises the question of how synchronized we want this file to be? It
seems a little arbitrary to me to synchronize the file from jessie to
wheezy only for this one certificate authority (LE). How about the other
authorities? It doesn't seem like we should be calling the shots on
this: if we follow the Mozilla policies here, either we update all
supported suites at once, or we accept that some suites will have
outdated material.

I have therefore opened this specific discussion with the release team
in #867461 (in CC as well). Hopefully this will bring a consistent
policy.

For what it's worth, my opinion is that we should attempt to synchronize
certdata.txt (and blacklist.txt, for that matter) across all suites (but
not other changes to the packaging). This would remove another decision
point in our infrastructure and ensure harmonious X509 processing across
suites.

[1]: https://lists.debian.org/1490430746.9127.2.camel@debian.org

Thanks for any feedback. For now I'll hold on another week or so for the
wheezy update, since it seems unreasonable to push that update out
before jessie is updated and that question is resolved.

A.

-- 
We won't have a society if we destroy the environment.
                        - Margaret Mead

Message #76 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Paul Wise <pabs@debian.org>

To: Antoine Beaupré <anarcat@orangeseeds.org>

Cc: Michael Shuler <michael@pbandjelly.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 7 Jul 2017 12:13:59 +0800

On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:

> For what it's worth, my opinion is that we should attempt to synchronize
> certdata.txt (and blacklist.txt, for that matter) across all suites (but
> not other changes to the packaging). This would remove another decision
> point in our infrastructure and ensure harmonious X509 processing across
> suites.

I would like to see that happen too.

-- 
bye,
pabs

https://wiki.debian.org/PaulWise

Message #81 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Philipp Kern <pkern@debian.org>

To: Antoine Beaupré <anarcat@orangeseeds.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org

Cc: debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 7 Jul 2017 15:57:35 +0200

[Message part 1 (text/plain, inline)]

On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
> In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
> wheezy, I noticed the issue was also pending in jessie. Furthermore, the
> idea originally raised by pabs[1] was to also update the packages for
> the latest changes in certdata.txt in wheezy, including the ISRG Root
> for Let's Encrypt (LE).
> 
> While it should be fairly trivial to do this update, I wonder if the
> same logic should apply to jessie itself. Right now, jessie and stretch
> are synchronized, but that's only because there's an update pending in
> unstable to synchronize with the upstream 2.11 NSS database.
> 
> This raises the question of how synchronized we want this file to be? It
> seems a little arbitrary to me to synchronize the file from jessie to
> wheezy only for this one certificate authority (LE). How about the other
> authorities? It doesn't seem like we should be calling the shots on
> this: if we follow the Mozilla policies here, either we update all
> supported suites at once, or we accept that some suites will have
> outdated material.
> 
> I have therefore opened this specific discussion with the release team
> in #867461 (in CC as well). Hopefully this will bring a consistent
> policy.
> 
> For what it's worth, my opinion is that we should attempt to synchronize
> certdata.txt (and blacklist.txt, for that matter) across all suites (but
> not other changes to the packaging). This would remove another decision
> point in our infrastructure and ensure harmonious X509 processing across
> suites.
> 
> [1]: https://lists.debian.org/1490430746.9127.2.camel@debian.org
> 
> Thanks for any feedback. For now I'll hold on another week or so for the
> wheezy update, since it seems unreasonable to push that update out
> before jessie is updated and that question is resolved.

But it's not just about certdata.txt. The WoSign and StartCom distrust
was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
couldn't check in any other tools using ca-certificates. We also do not
sync the NSS version or backport the cert checks when such distrusts
happen. So we can only react in a similar way when the time for full
distrust has come (which is sort of the case now with these two),
otherwise we diverge in logic and potentially break users with different
expectations[1].

Kind regards
Philipp Kern

[1] If they are realistic is another question.

[signature.asc (application/pgp-signature, attachment)]

Message #86 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Philipp Kern <pkern@debian.org>

Cc: Antoine Beaupré <anarcat@orangeseeds.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 7 Jul 2017 16:02:51 +0200

[Message part 1 (text/plain, inline)]

On Fri, Jul 07, 2017 at 03:57:35PM +0200, Philipp Kern wrote:
> On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
> > In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
> > wheezy, I noticed the issue was also pending in jessie. Furthermore, the
> > idea originally raised by pabs[1] was to also update the packages for
> > the latest changes in certdata.txt in wheezy, including the ISRG Root
> > for Let's Encrypt (LE).
> > 
> > While it should be fairly trivial to do this update, I wonder if the
> > same logic should apply to jessie itself. Right now, jessie and stretch
> > are synchronized, but that's only because there's an update pending in
> > unstable to synchronize with the upstream 2.11 NSS database.
> > 
> > This raises the question of how synchronized we want this file to be? It
> > seems a little arbitrary to me to synchronize the file from jessie to
> > wheezy only for this one certificate authority (LE). How about the other
> > authorities? It doesn't seem like we should be calling the shots on
> > this: if we follow the Mozilla policies here, either we update all
> > supported suites at once, or we accept that some suites will have
> > outdated material.
> > 
> > I have therefore opened this specific discussion with the release team
> > in #867461 (in CC as well). Hopefully this will bring a consistent
> > policy.
> > 
> > For what it's worth, my opinion is that we should attempt to synchronize
> > certdata.txt (and blacklist.txt, for that matter) across all suites (but
> > not other changes to the packaging). This would remove another decision
> > point in our infrastructure and ensure harmonious X509 processing across
> > suites.
> > 
> > [1]: https://lists.debian.org/1490430746.9127.2.camel@debian.org
> > 
> > Thanks for any feedback. For now I'll hold on another week or so for the
> > wheezy update, since it seems unreasonable to push that update out
> > before jessie is updated and that question is resolved.
> 
> But it's not just about certdata.txt. The WoSign and StartCom distrust
> was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
> couldn't check in any other tools using ca-certificates. We also do not
> sync the NSS version or backport the cert checks when such distrusts
> happen. So we can only react in a similar way when the time for full
> distrust has come (which is sort of the case now with these two),
> otherwise we diverge in logic and potentially break users with different
> expectations[1].

Which brings us back to #824872 (same nss/nspr in all suites). We're
basically shipping new NSS with firefox / thunderbird but not for the
rest.
 -- Guido

> 
> Kind regards
> Philipp Kern
> 
> [1] If they are realistic is another question.
> 
> 

[signature.asc (application/pgp-signature, inline)]

Message #91 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: Guido Günther <agx@sigxcpu.org>, Philipp Kern <pkern@debian.org>

Cc: Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Mon, 17 Jul 2017 15:41:05 -0400

On 2017-07-07 16:02:51, Guido Günther wrote:
> On Fri, Jul 07, 2017 at 03:57:35PM +0200, Philipp Kern wrote:
>> On 07/06/2017 08:01 PM, Antoine Beaupré wrote:
>> > In looking at fixing #858539 (blocking WoSign and StartCom, in CC) for
>> > wheezy, I noticed the issue was also pending in jessie. Furthermore, the
>> > idea originally raised by pabs[1] was to also update the packages for
>> > the latest changes in certdata.txt in wheezy, including the ISRG Root
>> > for Let's Encrypt (LE).
>> > 
>> > While it should be fairly trivial to do this update, I wonder if the
>> > same logic should apply to jessie itself. Right now, jessie and stretch
>> > are synchronized, but that's only because there's an update pending in
>> > unstable to synchronize with the upstream 2.11 NSS database.
>> > 
>> > This raises the question of how synchronized we want this file to be? It
>> > seems a little arbitrary to me to synchronize the file from jessie to
>> > wheezy only for this one certificate authority (LE). How about the other
>> > authorities? It doesn't seem like we should be calling the shots on
>> > this: if we follow the Mozilla policies here, either we update all
>> > supported suites at once, or we accept that some suites will have
>> > outdated material.
>> > 
>> > I have therefore opened this specific discussion with the release team
>> > in #867461 (in CC as well). Hopefully this will bring a consistent
>> > policy.
>> > 
>> > For what it's worth, my opinion is that we should attempt to synchronize
>> > certdata.txt (and blacklist.txt, for that matter) across all suites (but
>> > not other changes to the packaging). This would remove another decision
>> > point in our infrastructure and ensure harmonious X509 processing across
>> > suites.
>> > 
>> > [1]: https://lists.debian.org/1490430746.9127.2.camel@debian.org
>> > 
>> > Thanks for any feedback. For now I'll hold on another week or so for the
>> > wheezy update, since it seems unreasonable to push that update out
>> > before jessie is updated and that question is resolved.
>> 
>> But it's not just about certdata.txt. The WoSign and StartCom distrust
>> was actually hardcoded in NSS and hence what Mozilla enforced in NSS we
>> couldn't check in any other tools using ca-certificates. We also do not
>> sync the NSS version or backport the cert checks when such distrusts
>> happen. So we can only react in a similar way when the time for full
>> distrust has come (which is sort of the case now with these two),
>> otherwise we diverge in logic and potentially break users with different
>> expectations[1].
>
> Which brings us back to #824872 (same nss/nspr in all suites). We're
> basically shipping new NSS with firefox / thunderbird but not for the
> rest.

Let's not jump the gun here. We're not shipping NSS in ca-certificates,
just a tiny part of it: one text file, more or less.

Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
other ways, through the use of a blacklist.txt file. So we can
definitely fix #858539 without syncing all of NSS to wheezy.

The proposed patch here, is more or less only to merge that very file,
blacklist.txt. The *other* thing proposed to the release team (in
#867461) is to sync the *other* changes to certdata.txt from sid. But
considering *that* work seems mostly stalled, I wonder how hard to push
on that. Of course, we could also just decide, in LTS, to sync with
jessie at least: we do not need release-team approval for this. This
would be (let's be honest here) really to get Let's Encrypt directly in
wheezy, and I think it would be worthwhile.

Also I would very well see another NMU that would release those new
changes and sync up ca-certificates with NSS, at least in sid. Then it
could trickle down to buster, and from there, if everyone is okay,
trickle down to all suites. But that discussion concerns mostly the
release team and the maintainer at this point.

I'm not sure I want to bring back the question of syncing NSS across all
suites here again. It's a different question: NSS is a library, not
just a set of policies and certificates (which is, after all, what
ca-certificates is). Backporting it forcefully across all suites
may/will have an impact on programs that link against it, something that
we won't have with ca-certicates.

So while I would like NSS to be sync'd across suites as well, I'd like
to keep the questions separate here because ca-certificates is easier to
fix.

Thanks for your feedback, keep it coming.

A.

-- 
L'homme construit des maisons parce qu'il est vivant, mais il écrit des
livres parce qu'il se sait mortel.
                        - Daniel Pennac, Comme un roman

Message #96 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Michael Shuler <michael@pbandjelly.org>

To: Paul Wise <pabs@debian.org>, 858539@bugs.debian.org, Antoine Beaupré <anarcat@orangeseeds.org>

Cc: ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 867461@bugs.debian.org

Subject: Re: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

Date: Wed, 19 Jul 2017 11:35:56 -0500

On 07/06/2017 11:13 PM, Paul Wise wrote:
> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:
> 
>> For what it's worth, my opinion is that we should attempt to synchronize
>> certdata.txt (and blacklist.txt, for that matter) across all suites (but
>> not other changes to the packaging). This would remove another decision
>> point in our infrastructure and ensure harmonious X509 processing across
>> suites.
> 
> I would like to see that happen too.

I spent a few sessions over the past few days getting the mozilla bundle
2.14 committed to all the suite branches wheezy and newer. I have some
more verification to work on and I'll get some packages rolled up and
tested for all the suites.

I appreciate the notes here!

-- 
Kind regards,
Michael

Message #101 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, 858539@bugs.debian.org

Cc: ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 867461@bugs.debian.org

Subject: Re: Bug#858539: should ca-certificates certdata.txt synchronize across all suites?

Date: Wed, 19 Jul 2017 12:52:39 -0400

On 2017-07-19 11:35:56, Michael Shuler wrote:
> On 07/06/2017 11:13 PM, Paul Wise wrote:
>> On Fri, Jul 7, 2017 at 2:01 AM, Antoine Beaupré wrote:
>> 
>>> For what it's worth, my opinion is that we should attempt to synchronize
>>> certdata.txt (and blacklist.txt, for that matter) across all suites (but
>>> not other changes to the packaging). This would remove another decision
>>> point in our infrastructure and ensure harmonious X509 processing across
>>> suites.
>> 
>> I would like to see that happen too.
>
> I spent a few sessions over the past few days getting the mozilla bundle
> 2.14 committed to all the suite branches wheezy and newer. I have some
> more verification to work on and I'll get some packages rolled up and
> tested for all the suites.
>
> I appreciate the notes here!

Thanks!

let us know if you need help with the LTS bits.

a.

-- 
On reconnait la grandeur et la valeur d'une nation à la façon dont
celle-ci traite ses animaux.
                        - Mahatma Gandhi

Message #106 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Philipp Kern <pkern@debian.org>

To: Antoine Beaupré <anarcat@orangeseeds.org>, Guido Günther <agx@sigxcpu.org>

Cc: Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Thu, 20 Jul 2017 18:15:00 +0200

[Message part 1 (text/plain, inline)]

On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
> Let's not jump the gun here. We're not shipping NSS in ca-certificates,
> just a tiny part of it: one text file, more or less.

Yeah, and the consensus of the world external to Debian seems to be that
this might not be the smartest choice.

> Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
> other ways, through the use of a blacklist.txt file. So we can
> definitely fix #858539 without syncing all of NSS to wheezy.

That is incorrect. nss/lib/certhigh/certvfy.c contains code specific to
the StartCom/WoSign mitigation. Now the time has come for full distrust,
we can sync dropping the certs entirely by adding them to blacklist.txt,
sure. (Although they will continue to live on in the NSS source
additionally.)

But my point stands that in the next round of distrust (say, uh,
Symantec), we might actually need to push code changes to NSS.

> The proposed patch here, is more or less only to merge that very file,
> blacklist.txt. The *other* thing proposed to the release team (in
> #867461) is to sync the *other* changes to certdata.txt from sid. But
> considering *that* work seems mostly stalled, I wonder how hard to push
> on that. Of course, we could also just decide, in LTS, to sync with
> jessie at least: we do not need release-team approval for this. This
> would be (let's be honest here) really to get Let's Encrypt directly in
> wheezy, and I think it would be worthwhile.

I think it's useful to phrase the goal which is:

- Remove StartCom
- Remove WoSign
- Add Let's Encrypt

Which is easier to get behind than "should we synchronize the file".

What's the timeline on Let's Encrypt dropping the cross certification?
Is that actually planned? Because the whole point of that was that
adding LE directly isn't actually critical. (And people should use the
chain provided by ACME rather than relying on certificates shipped by
Debian.)

Kind regards
Philipp Kern

[signature.asc (application/pgp-signature, attachment)]

Message #111 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: Philipp Kern <pkern@debian.org>, Guido Günther <agx@sigxcpu.org>

Cc: Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 21 Jul 2017 09:51:45 -0400

On 2017-07-20 18:15:00, Philipp Kern wrote:
> On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
>> Let's not jump the gun here. We're not shipping NSS in ca-certificates,
>> just a tiny part of it: one text file, more or less.
>
> Yeah, and the consensus of the world external to Debian seems to be that
> this might not be the smartest choice.

I'm not sure I understand what you are proposing as an alternative
here. Should we stop shipping ca-certificates? Or make it a binary
package of the NSS source package?

>> Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
>> other ways, through the use of a blacklist.txt file. So we can
>> definitely fix #858539 without syncing all of NSS to wheezy.
>
> That is incorrect. nss/lib/certhigh/certvfy.c contains code specific to
> the StartCom/WoSign mitigation. Now the time has come for full distrust,
> we can sync dropping the certs entirely by adding them to blacklist.txt,
> sure. (Although they will continue to live on in the NSS source
> additionally.)

I don't understand this: how is it incorrect? #858539 applies only to
ca-certificates, and can be fixed without patching NSS.

Now to update the NSS package itself is another question, again.

> But my point stands that in the next round of distrust (say, uh,
> Symantec), we might actually need to push code changes to NSS.

Sure, but that doesn't necessarily affect ca-certificates directly, in
that we can update ca-certificates orthogonally right now.

>> The proposed patch here, is more or less only to merge that very file,
>> blacklist.txt. The *other* thing proposed to the release team (in
>> #867461) is to sync the *other* changes to certdata.txt from sid. But
>> considering *that* work seems mostly stalled, I wonder how hard to push
>> on that. Of course, we could also just decide, in LTS, to sync with
>> jessie at least: we do not need release-team approval for this. This
>> would be (let's be honest here) really to get Let's Encrypt directly in
>> wheezy, and I think it would be worthwhile.
>
> I think it's useful to phrase the goal which is:
>
> - Remove StartCom
> - Remove WoSign
> - Add Let's Encrypt
>
> Which is easier to get behind than "should we synchronize the file".

Sure. The point I was trying to make here was that we seem to be
favoring certain well-known CAs over other less well-known. I'm actually
with that (e.g. because I don't like Amazon very much), but I'm not sure
that's a position that should be reflected in our work.

> What's the timeline on Let's Encrypt dropping the cross certification?
> Is that actually planned? Because the whole point of that was that
> adding LE directly isn't actually critical. (And people should use the
> chain provided by ACME rather than relying on certificates shipped by
> Debian.)

I can't answer those questions, unfortunately, but it's a fair point.

Pabs? What was the idea behind migrating LE down to wheezy?

A.

-- 
La publicité est la dictature invisible de notre société.
                        - Jacques Ellul

Message #116 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@orangeseeds.org>

To: Philipp Kern <pkern@debian.org>

Cc: Guido Günther <agx@sigxcpu.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org, Kurt Roeckx <kroeckx@debian.org>

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 21 Jul 2017 16:47:23 -0400

On 2017-07-21 22:19:20, Philipp Kern wrote:
> My point was that you state what your delta is and essentially boils 
> down to attach the diff of what will actually happen to the .deb. I 
> think it's generally fine to add new CAs and remove fully distrusted 
> ones, instead of saying "it should just be in sync with unstable". The 
> latter contains a lot more nuance if you know that some of the rules are 
> only available in code.

Thank you for taking the time to clarify your position, I understand it
much better now. :)

Makes perfect sense, I'll try to be clearer in future communications to
avoid such confusion.

A.

-- 
Si les triangles avaient un Dieu, ils lui donneraient trois côtés.
                        - Montesquieu, Lettres persanes

Message #121 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Moritz Mühlenhoff <jmm@inutil.org>

To: Antoine Beaupré <anarcat@orangeseeds.org>

Cc: Philipp Kern <pkern@debian.org>, Guido Günther <agx@sigxcpu.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 21 Jul 2017 23:03:22 +0200

On Fri, Jul 21, 2017 at 09:51:45AM -0400, Antoine Beaupré wrote:
> On 2017-07-20 18:15:00, Philipp Kern wrote:
> > On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
> >> Let's not jump the gun here. We're not shipping NSS in ca-certificates,
> >> just a tiny part of it: one text file, more or less.
> >
> > Yeah, and the consensus of the world external to Debian seems to be that
> > this might not be the smartest choice.
> 
> I'm not sure I understand what you are proposing as an alternative
> here. Should we stop shipping ca-certificates? Or make it a binary
> package of the NSS source package?

Most distros rebase to the latest NSS release across all supported suites.

We also did this once or twice in -security (for changes which were too
instrusive to backport) and upstream apparently usually supports this.

But it's quite some effort to test all the reverse deps (that's why backporting
isolated fixes is easier in such cases) to ensure no breakage creeps in, so
this would need a volunteer to deal with testing reverse deps.

Cheers,
        Moritz

Message #126 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Guido Günther <agx@sigxcpu.org>

To: Moritz Mühlenhoff <jmm@inutil.org>

Cc: Antoine Beaupré <anarcat@orangeseeds.org>, Philipp Kern <pkern@debian.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 21 Jul 2017 23:59:42 +0200

Hi,
On Fri, Jul 21, 2017 at 11:03:22PM +0200, Moritz Mühlenhoff wrote:
> On Fri, Jul 21, 2017 at 09:51:45AM -0400, Antoine Beaupré wrote:
> > On 2017-07-20 18:15:00, Philipp Kern wrote:
> > > On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
> > >> Let's not jump the gun here. We're not shipping NSS in ca-certificates,
> > >> just a tiny part of it: one text file, more or less.
> > >
> > > Yeah, and the consensus of the world external to Debian seems to be that
> > > this might not be the smartest choice.
> > 
> > I'm not sure I understand what you are proposing as an alternative
> > here. Should we stop shipping ca-certificates? Or make it a binary
> > package of the NSS source package?
> 
> Most distros rebase to the latest NSS release across all supported suites.
> 
> We also did this once or twice in -security (for changes which were too
> instrusive to backport) and upstream apparently usually supports this.
> 
> But it's quite some effort to test all the reverse deps (that's why backporting
> isolated fixes is easier in such cases) to ensure no breakage creeps in, so
> this would need a volunteer to deal with testing reverse deps.

Which could be mitigated via p-u since this at least allows others
(including machines that build all the rdeps and run the autopkg tests)
to see things before the hit everybody running stable.
Cheers,
 -- Guido

Message #131 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Kurt Roeckx <kurt@roeckx.be>

To: Antoine Beaupré <anarcat@orangeseeds.org>

Cc: Philipp Kern <pkern@debian.org>, Guido Günther <agx@sigxcpu.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Sat, 22 Jul 2017 11:43:07 +0200

On Fri, Jul 21, 2017 at 04:47:23PM -0400, Antoine Beaupré wrote:
> On 2017-07-21 22:19:20, Philipp Kern wrote:
> > My point was that you state what your delta is and essentially boils 
> > down to attach the diff of what will actually happen to the .deb. I 
> > think it's generally fine to add new CAs and remove fully distrusted 
> > ones, instead of saying "it should just be in sync with unstable". The 
> > latter contains a lot more nuance if you know that some of the rules are 
> > only available in code.
> 
> Thank you for taking the time to clarify your position, I understand it
> much better now. :)
> 
> Makes perfect sense, I'll try to be clearer in future communications to
> avoid such confusion.

Mozilla has various extra distrust/partial trust rules that are now
coded in either NSS or Firefox itself. But we're not even using the
distrust/partial trust information currently in certdata.txt.

Other than what is in certdata.txt + code, there are also
certificates that are distrusted by using OneCRL.

I currently see no reason not to ship certdata.txt in all
distributions.

In any case, I think we should try to implement all the rules that
Mozilla applies in all software that deals with certificate. And
at least Mozilla is interested in that, and at least some of the
OpenSSL people would also like to see OpenSSL have more checks
than that currently happen.


Kurt

Message #136 received at 858539@bugs.debian.org (full text, mbox, reply):

From: Philipp Kern <pkern@debian.org>

To: Antoine Beaupré <anarcat@orangeseeds.org>

Cc: Guido Günther <agx@sigxcpu.org>, Michael Shuler <michael@pbandjelly.org>, Paul Wise <pabs@debian.org>, ca-certificates@packages.debian.org, debian-lts@lists.debian.org, 858539@bugs.debian.org, 867461@bugs.debian.org, Kurt Roeckx <kroeckx@debian.org>

Subject: Re: should ca-certificates certdata.txt synchronize across all suites?

Date: Fri, 21 Jul 2017 22:19:20 +0200

On 2017-07-21 15:51, Antoine Beaupré wrote:
> On 2017-07-20 18:15:00, Philipp Kern wrote:
>> On 07/17/2017 09:41 PM, Antoine Beaupré wrote:
>>> Let's not jump the gun here. We're not shipping NSS in 
>>> ca-certificates,
>>> just a tiny part of it: one text file, more or less.
>> Yeah, and the consensus of the world external to Debian seems to be 
>> that
>> this might not be the smartest choice.
> I'm not sure I understand what you are proposing as an alternative
> here. Should we stop shipping ca-certificates? Or make it a binary
> package of the NSS source package?

I don't think anyone has a good answer to this right now as the 
additional restrictions on CAs to implement distrust are generally not 
machine-readable these days and especially not supported cross-library.

>>> Also, what Mozilla enforced in NSS, we enforced in ca-certificates in
>>> other ways, through the use of a blacklist.txt file. So we can
>>> definitely fix #858539 without syncing all of NSS to wheezy.
>> 
>> That is incorrect. nss/lib/certhigh/certvfy.c contains code specific 
>> to
>> the StartCom/WoSign mitigation. Now the time has come for full 
>> distrust,
>> we can sync dropping the certs entirely by adding them to 
>> blacklist.txt,
>> sure. (Although they will continue to live on in the NSS source
>> additionally.)
> 
> I don't understand this: how is it incorrect? #858539 applies only to
> ca-certificates, and can be fixed without patching NSS.
> 
> Now to update the NSS package itself is another question, again.

So that was a mismatch of expectations. You said "what Mozilla enforced 
in NSS" and you meant the full distrust. I meant the partial one. I now 
see [0], which is for the full one, which is fine (which is also what I 
said).

>> But my point stands that in the next round of distrust (say, uh,
>> Symantec), we might actually need to push code changes to NSS.
> 
> Sure, but that doesn't necessarily affect ca-certificates directly, in
> that we can update ca-certificates orthogonally right now.

Sure.

>>> The proposed patch here, is more or less only to merge that very 
>>> file,
>>> blacklist.txt. The *other* thing proposed to the release team (in
>>> #867461) is to sync the *other* changes to certdata.txt from sid. But
>>> considering *that* work seems mostly stalled, I wonder how hard to 
>>> push
>>> on that. Of course, we could also just decide, in LTS, to sync with
>>> jessie at least: we do not need release-team approval for this. This
>>> would be (let's be honest here) really to get Let's Encrypt directly 
>>> in
>>> wheezy, and I think it would be worthwhile.
>> 
>> I think it's useful to phrase the goal which is:
>> 
>> - Remove StartCom
>> - Remove WoSign
>> - Add Let's Encrypt
>> 
>> Which is easier to get behind than "should we synchronize the file".
> 
> Sure. The point I was trying to make here was that we seem to be
> favoring certain well-known CAs over other less well-known. I'm 
> actually
> with that (e.g. because I don't like Amazon very much), but I'm not 
> sure
> that's a position that should be reflected in our work.

My point was that you state what your delta is and essentially boils 
down to attach the diff of what will actually happen to the .deb. I 
think it's generally fine to add new CAs and remove fully distrusted 
ones, instead of saying "it should just be in sync with unstable". The 
latter contains a lot more nuance if you know that some of the rules are 
only available in code.

Kind regards and thanks for your work
Philipp Kern

[0] 
https://anonscm.debian.org/cgit/collab-maint/ca-certificates.git/plain/mozilla/blacklist.txt

Send a report that this bug log contains spam.