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

["Daniel P. Berrangé" <berrange@redhat.com>]

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.

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

> > > > + * The maintainer(s) will update the commit message(s)
> > > 
> > > what does it mean to "update the commit message"?
> > 
> > The commit message for the patch the maintainer has in their
> > tree.
> 
> then you mean "before sending a pull request"?

Sure if you want it to be that specific.

> > > > to include
> > > > +   the assigned CVE and issue URL. If multiple commits are required
> > > > +   to fix an issue the CVE must be included in the final commit in
> > > > +   the series, and may optionally be included in all prior commits.
> > > 
> > > And here, included in what format?
> > 
> > The CVE just needs to exist somewhere/anywhere in the commit message.
> > It is common to put it in the first line, or with tags before SoB
> > but it doesn't really matter as long as we have a record of it in
> > the patch.
> 
> Will be really annoying if any tools try to consume this e.g.
> to decide what to backport.
> I suggest deciding on something for these free text fields,
> how important is it to be able to write ❤️❤️❤️CVE-1234💰🔥🎯 really?

I don't think we need to document every single little detail
here, just carry on with what we've already been doing for
commits.

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