Bug#858539: 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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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 Description: OpenPGP digital signature
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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.ca...@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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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.ca...@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 Description: PGP signature
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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.ca...@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 Description: OpenPGP digital signature
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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
Bug#858539: should ca-certificates certdata.txt synchronize across all suites?
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.ca...@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
