Re: NSS and logjam in wheezy (CVE-2015-4000)
Hi Guido,
On Thu, May 19, 2016 at 08:11:37AM +0200, Guido Günther wrote:
> On Wed, May 18, 2016 at 03:12:23PM -0400, Antoine Beaupré wrote:
> > On 2016-03-29 16:28:36, Antoine Beaupré wrote:
> > > On 2016-03-26 04:33:29, Guido Günther wrote:
> > >> Thanks for reviewing this! I was about to look into more recent nss
> > >> issues after handling dhcpcd but since you're at it, go ahead!
> > >>
> > >> Note that we still have CVE-2015-4000 which would most easily be fixed
> > >> by having the same nss in all suites but since I got zero feedback from
> > >> the release team going that route doesn't seem to be an option. We could
> > >> still handle this via sec updates though.
> > >
> > > So I am not sure how to deal with CVE-2015-4000. The patch is
> > > substantial:
> > >
> > > https://hg.mozilla.org/projects/nss/rev/ae72d76f8d24
> >
> > I just sent the DLA for NSS as is, without a fix for CVE-2015-4000. I am
> > actually sorry I forgot about this issue, as I would have liked to use
> > the opportunity of the DLA to clarify our position on logjam and TLS 1.2
> > in wheezy.
> >
> > Unfortunately, we still have to clarify that position now. :)
> >
> > So far, I'm tempted to just mark the issue as <no-dsa> (too intrusive to
> > backport), and considering how debian-release doesn't seem sympathetic
> > to the idea of maintaining a similar nss version across suites.
>
> Bringing up the "same nss in all suites" issue again is on my todo list
> once I'm finished with icedove. There wasn't any feedback to my post[1]
> so far though. We could still go through {jessie,wheezy}-security if the
> security team agrees?
Not sure if I missed something. But if we haven't had a reply from SRM
on [1], maybe it is better to open a bug with that question raised
against release.debian.org. In past SRM have said that they prefer to
have an actual bug (e.g. as well for other requests instead of a post
to the release mailinglist). It just might have slept trough.
Could you do that? I think we should really go trough that path and
have .e.g then the packages first esposed in the
$codename-proposed-updates instead of pushing the "same nss in all
suites + version bump" via -security.
Regards,
Salvatore
Reply to: