[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 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
Reply to: