Re: should ca-certificates certdata.txt synchronize across all suites?
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
Yeah, and the consensus of the world external to Debian seems to be
just a tiny part of it: one text file, more or less.
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
the StartCom/WoSign mitigation. Now the time has come for full
we can sync dropping the certs entirely by adding them to
sure. (Although they will continue to live on in the NSS source
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 , which is for the full one, which is fine (which is also what I
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
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
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
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
with that (e.g. because I don't like Amazon very much), but I'm not
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