On Fri, Nov 06, 2026 at 10:17:02AM +0000, Peter Maydell wrote: > On Fri, 6 Nov 2026 at 09:22, Daniel P. Berrangé <[email protected]> wrote: > > > > On Fri, Nov 06, 2026 at 12:15:06PM +0300, Michael Tokarev wrote: > > > Hi! > > > > > > What's the way you use to find these patches, with security impact or not? > > > > > > I usually quickly screen all new commits in the master branch, and often > > > catch things which aren't marked for-stable, - not everything of interest > > > is marked as such. I also tend to remind the maintainers about these > > > markings. But my resources here are limited, I can't try to understand > > > every patch, even description of it. > > > > > > How do you perform a security review? > > > > FWIW, with our new security triage process, we should be fairly > > reliably getting issues in gitlab tagged with CVE::Assigned, if > > they have been accepted as an in-scope security issue and had a > > CVE assigned. > > I think in this case we're talking about #4802 (confidential), > and the problem is that the commits in question were not given > a CVE or tagged for stable, because it wasn't realised at the time > that they were fixing a bug.
Ah ok, and those commits in master pre-dated our new CVE workflow. In this kind of situation where we miss security implications initially, if the flaw is considered significant enough, we could potentially retrospectively request to assign a CVE for an already merged fix. With regards, Daniel -- |: https://berrange.com ~~ https://hachyderm.io/@berrange :| |: https://libvirt.org ~~ https://entangle-photo.org :| |: https://pixelfed.art/berrange ~~ https://fstop138.berrange.com :|
