nss update for jessie

[Mike Hommey]

On Sun, Oct 02, 2016 at 10:22:34AM +0200, Florian Weimer wrote:
> * Mike Hommey:
> 
> > On Sun, Oct 02, 2016 at 08:39:03AM +0200, Florian Weimer wrote:
> >> * Mike Hommey:
> >> 
> >> > On Sat, Oct 01, 2016 at 09:20:49PM +0200, Florian Weimer wrote:
> >> >> Hi Mike and all,
> >> >> 
> >> >> I'm looking at the possibility of a nss security update for jessie.
> >> >> 
> >> >> Do you suggest to rebase the package to a later upstream maintenance
> >> >> release, or to backport individual patches?
> >> >
> >> > The former is more tractable, although you'd get in the issue of
> >> > possibly changed defaults.
> >> 
> >> But sometimes, the security fix is in the changed defaults.
> >> 
> >> I know that historically, NSS relied on application updates to
> >> implement changing cipher preferences (in the sense that “if your
> >> application negotiated this cipher suite in 1998, you certainly want
> >> it to pick the same suite today”).  But this means that all
> >> applications need to be patched for cipher deprecations and
> >> introduction of new ciphers (such as ECC).  I don't think this matches
> >> current user expectations.
> >> 
> >> I saw the most recent upstream release compiles in necessarily
> >> incomplete TLS 1.3 support.  *This* is not something what we want, and
> >> I wonder what other traps are in the code base.
> >
> > Note there's likely going to be another upstream release to fix that
> > particular issue. Also note that that particular problematic upstream
> > release is not in Debian yet.
> 
> Right, and it does not seem contain security fixes we need.
> 
> If I want to move forward with the rebase, would you recommend to
> start with the version in sid and roll back packaging changes we do
> not want, or go the opposite direction, upgrading the jessie version
> to the 3.26 and pick up only minimum required changes (mostly related
> to symbol versioning, it seems)?

I'd go with the latter. You'll have conflict in the debian/patches, it
might be easier to pick the corresponding ones from the package in
unstable.

You might want to consider removing the SPI CA certificate too (done in
2:3.21-1)

Mike