RFC: GitLab confidential issues for security disclosures ?
The QEMU project has just changed to use GitLab confidential issues for security disclosures. https://www.qemu.org/contribute/security-process/ While libvirt isn't (yet) suffering the same massive AI powered bug tsunami, I'm not seeing an especially compelling reason to continue using email for security disclosures with such limited need-to-know practices. While using GitLab theoretically exposes us to greater risk of exposure via the GitLab's own staff / infra compromise, in practice they likely do a better job securing their infra than we do for our mailman install. Submissions are also guaranteed TLS protection which we can't so confidently assume for email. We don't tend to apply any long embargo times. Our maintainers are all trusted with commit access to libvirt.git, so from a trust POV I feel it acceptable to have scurity disclosures visible to all of them instead of restricted to a handful of maintainers. The security list has a handful of people from the distro present who in theory can watch it for early access to disclosures. I'm not sure if that makes a difference in practice though, especially with all the distros suffering an AI bug tsunami leading to greatly extended fix times. IOW, overall a lighter weight process using GitLab confidential issues feels like it should be sufficient for libvirt too. 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 :|
On a Wednesday in 2026, Daniel P. Berrangé via Devel wrote:
The QEMU project has just changed to use GitLab confidential issues for security disclosures.
https://www.qemu.org/contribute/security-process/
While libvirt isn't (yet) suffering the same massive AI powered bug tsunami, I'm not seeing an especially compelling reason to continue using email for security disclosures with such limited need-to-know practices.
I did not follow the QEMU discussion leading up to this, but I think you're mixing up two arguments here - no longer using e-mail and disclosing it to a wider audience.
While using GitLab theoretically exposes us to greater risk of exposure via the GitLab's own staff / infra compromise, in practice they likely do a better job securing their infra than we do for our mailman install. Submissions are also guaranteed TLS protection which we can't so confidently assume for email.
We don't tend to apply any long embargo times. Our maintainers are all trusted with commit access to libvirt.git, so from a trust POV I feel it acceptable to have scurity disclosures visible to all of them instead of restricted to a handful of maintainers.
Agreed.
The security list has a handful of people from the distro present who in theory can watch it for early access to disclosures. I'm not sure if that makes a difference in practice though, especially with all the distros suffering an AI bug tsunami leading to greatly extended fix times.
Aren't they libvirt maintainers already?
IOW, overall a lighter weight process using GitLab confidential issues feels like it should be sufficient for libvirt too.
I'm indifferent to the switch to GitLab, but I don't consider it anymore lightweight than e-mail. Do you have a link to the QEMU discussion? Jano
On Wed, Jul 08, 2026 at 04:47:47PM +0200, Ján Tomko wrote:
On a Wednesday in 2026, Daniel P. Berrangé via Devel wrote:
The QEMU project has just changed to use GitLab confidential issues for security disclosures.
https://www.qemu.org/contribute/security-process/
While libvirt isn't (yet) suffering the same massive AI powered bug tsunami, I'm not seeing an especially compelling reason to continue using email for security disclosures with such limited need-to-know practices.
I did not follow the QEMU discussion leading up to this, but I think you're mixing up two arguments here - no longer using e-mail and disclosing it to a wider audience.
True, we conflated the two originally too. Historically security bug disclosure processes involved a very tightly controlled audience, so only a handful of maintainers would be aware of them initially. We used a private email lists as a way to easily manage which people get CCd, even though this did expose disclosures to admins of the mailman service. We couldn't use GitLab as its coarse permissions model means any project member with "Reporter" role or higher can view confidential issues. If we assume we don't want the tight "need to know" restrictions, then we don't need to manage CC lists in the same way. This means we don't suffer from GitLab's coarse permissions model, anjd thus confidential issues are viable.
While using GitLab theoretically exposes us to greater risk of exposure via the GitLab's own staff / infra compromise, in practice they likely do a better job securing their infra than we do for our mailman install. Submissions are also guaranteed TLS protection which we can't so confidently assume for email.
We don't tend to apply any long embargo times. Our maintainers are all trusted with commit access to libvirt.git, so from a trust POV I feel it acceptable to have scurity disclosures visible to all of them instead of restricted to a handful of maintainers.
Agreed.
The security list has a handful of people from the distro present who in theory can watch it for early access to disclosures. I'm not sure if that makes a difference in practice though, especially with all the distros suffering an AI bug tsunami leading to greatly extended fix times.
Aren't they libvirt maintainers already?
No, we have a handful of distro people who joined as an "early disclosure" mechanism for non-public bugs. That concept was valid historically, but IMHO is no longer justified in the current world where AI can re-discover bugs independently many times over, killing the idea of non-public embargoed bugs.
IOW, overall a lighter weight process using GitLab confidential issues feels like it should be sufficient for libvirt too.
I'm indifferent to the switch to GitLab, but I don't consider it anymore lightweight than e-mail. Do you have a link to the QEMU discussion?
The overall goal was that security bug handling and non-security bug handling should be essentially identical. The only difference is that the former is initially confidential until a patch is posted to the mailing list at which point it is flipped to be a public bug. This means when the patch is merged the bug gets auto-closed in the normal way. You can query gitlab (filter label CVE::Assigned) to see all historical security bugs. If a security disclosure is declared to be not a security bug we don't have to ask the reporter to re-file in gitlab, we just remove the confidential flag. I can't find a link right now as mailman archive for gnu.org appears dead again :-( The published policy is https://www.qemu.org/contribute/security-process/ it is a whole lot of words, but ultimately it is just a normal gitlab bug handling process with a few special labels thrown in, and the confidential flag toggled. 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 :|
participants (2)
-
Daniel P. Berrangé -
Ján Tomko