Re: <no-dsa> (minor) vs. <ignored> ($not-fixable-because) (was: Re: gnutls/nettle (CVE-2018-16868/CVE-2018-16869))
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:
>> 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).
>>>> I also worked on nettle/gnutls26 for Wheezy. There are too many
>>>> 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
>>>> too intrusive.
>>> Thanks for your input Markus.
>>> Instead of upgrading I was thinking of providing libnettle6 /in
>>> to/ libnettle4, but that still sounds like more troubles than it
>> (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
> 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
Sure, I now avoid the vague <no-dsa> as much as I can, <ignored> sounds
adequate for this CVE resolution.