On Thu, Jun 18, 2026 at 05:55:36PM +0100, Daniel P. Berrangé wrote: > On Thu, Jun 18, 2026 at 12:39:31PM -0400, Michael S. Tsirkin wrote: > > On Thu, Jun 18, 2026 at 05:33:54PM +0100, Daniel P. Berrangé wrote: > > > On Thu, Jun 18, 2026 at 12:23:46PM -0400, Michael S. Tsirkin wrote: > > > > thanks! sorry probably just me being dense but some things > > > > here I don't get. might be worth clarifying: > > > > > > > > On Thu, Jun 18, 2026 at 05:07:10PM +0100, Daniel P. Berrangé wrote: > > > > > On Thu, Jun 18, 2026 at 11:30:29AM -0400, Michael S. Tsirkin wrote: > > > > > > > + * The maintainer(s) will develop and/or review patch(es) > > > > > > > + for the issue privately, optionally attaching work in > > > > > > > + progress fixes to the GitLab issues. > > > > > > > > > > > > attaching how? how do i ask reported to test the fix? > > > > > > was easy in the email flow. > > > > > > > > > > You can add arbitrary attachments in gitlab issue comments. > > > > > > > > > > > > All patches must > > > > > > > + include the issue URL in the commit message(s). > > > > > > > > > > > > you mean the commit message of the patches I presume? > > > > > > there's no commit at that point. > > > > > > > > > > Well I presume the maintainer will have a local git tree > > > > > with a work-in-progress commit. > > > > > > > > sorry I don't get it. > > > > > > > > what does it have to do with patches then? > > > > > > > > > > > > who cares about my local tree? > > > > > > If you fix a gitlab issue, the commit must contain the issue URL. > > > That's normal practice we've followed forever and would now apply > > > to security fixes too. > > > > Ah. You want a Fixes: tag maybe? Let's say so pls then. > > > > > > > > > > and why is this mentioned twice? > > > > > > Mentioning twice is a mistake > > > > > > > > > > > > > The > > > > > > > + **"Workflow::In Progress"** label should be assigned when > > > > > > > + a maintainer starts working on a fix. > > > > > > > > > > > > That's a bit heavy, and what is "working" anyway. > > > > > > It's an issue tracker not a planning app. > > > > > > Don't try to make it one. > > > > > > > > > > Various "Workflow::" labels are already present in our gitlab > > > > > instance. We don't use them consistently - this text is just > > > > > a pointer that the're there. > > > > > > > > > > > > > maybe "can be assigned" then? > > > > > > Ok. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > + * When a CVE is allocated, it must be recorded as a comment on > > > > > > > + the GitLab issue, and the **"CVE::Required"** label replaced > > > > > > > by > > > > > > > + the **"CVE::Assigned"** label. > > > > > > > > > > > > Recorded as a comment how exactly, in what format? > > > > > > > > > > In plain text. > > > > > > > > yes but in what format? > > > > > > Literally just "CVE-2026-1234" anywhere in the commit message as we've > > > been donig for years. > > > > I suspect what we've been doing for years no longer scales or > > we'd keep doing what we've been doing? > > > > > > We desperately need something that is consumable by tooling, > > and I just do not see how is a tool going to figure out > > "this seems to be unrelated CVE-123" is irrelevant. > > It depends who you mean by "we" here ? From an upstream POV I don't > think we care. We ship fixes in master.
Why do we bother with CVE numbers at all then? > While it would be nice to > have stable releases with all security fixes backported, we have > never promised/offered that and with the volume we see, I don't > think we should try to add such a promise either. > > IOW, consuming CVE fixes is largely a downstream problem. I'd > recommend they start from the gitlab issues with Kind::Security > and CVE::Assigned tags present, but beyon that its upto them. Let's say they do it, how do they know the CVE number? > > 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 :|
