Re: [qemu-web PATCH v2 3/3] contribute: switch security process to gitlab confidential issues

["Michael S. Tsirkin" <mst@redhat.com>]

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 :|