On Tue, 2020-05-19 at 19:34 +0200, Moritz Mühlenhoff wrote: > On Tue, May 19, 2020 at 11:59:05AM +0100, Luca Boccassi wrote: > > On Tue, 2020-05-19 at 12:51 +0200, Moritz Mühlenhoff wrote: > > > On Tue, May 19, 2020 at 10:02:46AM +0100, Luca Boccassi wrote: > > > > On Thu, 14 May 2020 22:57:44 +0100 Luca Boccassi < > > > > bl...@debian.org > > > > > wrote: > > > > > On Thu, 2020-05-14 at 18:50 +0100, Luca Boccassi wrote: > > > > > > Package: openconnect > > > > > > Version: 6.00-1 > > > > > > Severity: important > > > > > > Tags: security > > > > > > > > > > > > Openconnect is affected by a buffer overflow in certificate > > > > > > handling, > > > > > > that goes back at least to 6.00-1 (old-old-stable). > > > > > > > > > > > > Fixed upstream by: > > > > > > > > > > > > > > > > https://gitlab.com/openconnect/openconnect/-/merge_requests/108 > > > > > > > > > Dear security team, > > > > > > > > > > I uploaded to old-old-stable on request from the LTS team. How would > > > > > you like to handle stable and old-stable? > > > > > > > > Ping. Should I do an upload to security-master for buster-security and > > > > stretch-security? > > > > > > It's not really clear to me why this was assigned a CVE ID, this doesn't > > > appear to cross any reasonable trust boundary. Certificates need to come > > > from a trusted source, otherwise you have many other insecurities at hand. > > > > > > This appears to be "just a bug" (which would seem to reach the bar for > > > being fixed in a point update), but I can't see why this would need a DSA. > > > > > > I might totally miss something, ofc. So please correct me if I'm wrong :-) > > > > > > Cheers, > > > Moritz > > > > Hi, > > > > The upstream maintainer agrees that perhaps a CVE was not warranted. > > The only way this check could be done on an somewhat-external > > certificate is if it came from a PKCS#11 token, but it's pretty far > > fetched. > > > > Release notes say: > > > > "This release is brought to you by CVE-2020-12823; a buffer overflow > > when obtaining a pretty name to describe local certificates, when built > > against GnuTLS. Note that this isn't used for remote certificates; this > > is all local (client cert and supporting CAs provided locally) so not > > easily remotely triggerable." > > Thanks for doublechecking! > > As such, we don't need a DSA. You could target this for a point update > or we can stuff it in some git branch and piggyback on a potential > future DSA in case there's a DSA-relevant issue at some point? > > Cheers, > Moritz
Queueing for the next time around sounds like a good idea - pushed to the debian/buster branch. -- Kind regards, Luca Boccassi
signature.asc
Description: This is a digitally signed message part
