Hi, On Wed, May 20, 2020 at 09:22:11AM +0100, Luca Boccassi wrote: > 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.
With the fact that procedures for updates via point releases have been improved, it would be as well just be an option to upload for the next buster point release and have it already queued. Just as additional comment to the above. Regards, Salvatore
