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. > >
Attachment:
signature.asc
Description: PGP signature