Hi, On 30/08/2019 10:28, Mike Gabriel wrote: > Hi Sylvain, hi all, > > On Fr 08 Mär 2019 11:03:49 CET, Sylvain Beucler wrote: > >> Hi, >> >> On 04/03/2019 17:37, Sylvain Beucler wrote: >>> On 04/03/2019 16:55, Markus Koschany wrote: >>>> Am 04.03.19 um 16:33 schrieb Sylvain Beucler: >>>> [...] >>>>> I see this as a strong signal that we should not attempt to >>>>> backport the >>>>> fix, and go with a <no-dsa> (minor). >>>>> >>>>> Alternatively we could upgrade nettle (libnettle4->libnettle6) which >>>>> doesn't break gnutls28's test suite, though it's likely to introduce >>>>> other issues (e.g. #789119). >>>>> >>>>> Thoughts? >>>> I also worked on nettle/gnutls26 for Wheezy. There are too many >>>> changes >>>> and just backporting rsa_sec_decrypt in nettle would be an incomplete >>>> fix for CVE-2018-16869 because they introduced more hardening against >>>> those side-channel attacks in other functions. An upgrade of nettle >>>> would require a rebuild of all reverse-dependencies and that is >>>> probably >>>> too intrusive. >>> >>> Thanks for your input Markus. >>> >>> Instead of upgrading I was thinking of providing libnettle6 /in >>> addition >>> to/ libnettle4, but that still sounds like more troubles than it >>> solves. >> >> (and indeed, when testing gnutls28+libnettle6, "git clone" now fails.) >> # git clone https://github.com/symfony/symfony-installer >> Clonage dans 'symfony-installer'... >> fatal: unable to access 'https://github.com/symfony/symfony-installer/': >> gnutls_handshake() failed: Public key signature verification has failed. >> >> >> Also, the stable security team didn't answer my mail but reached the >> same conclusion (<no-dsa> minor). >> I'll mark these CVE-s as <no-dsa> and fix the CVE/list incomplete >> assessment. > > I am currently going through all CVEs listed by bin/lts-cve-triage.py > (in security-tracker Git repo (for those not acquainted to the > sectracker toolchain). > > Marking such CVEs (such as CVE-2018-16868/gnutls28/jessie) as > "<no-dsa> (minor issue)" is technically correct, I guess, but such > CVEs don't get explicitly marked by the output of lts-cve-triage.py. > When doing frontdesk work, you get drawn to those issues to at least > take another look. What was that CVE about, has there been some > communication regarding it, etc. > > However, if we tagged such CVEs as "<ignored> (too invasive to fix)", > the <ignored> tag would be shown in lts-cve-triage.py output and > "ignore" explains better what we should do with such CVEs when triaging. Glad to see my contribution to lts-cve-triage.py is being useful :) > I am inclined to adapt CVE-2018-16868 accordingly, unless people > contradict.
Sure, I now avoid the vague <no-dsa> as much as I can, <ignored> sounds adequate for this CVE resolution. Cheers! Sylvain
