Proposal: XSF as a CVE Numbering Authority (CNA)
Hi folks, Most of you are probably familiar with CVEs. They're like universal bug numbers for security vulnerabilities. They make it much easier to exchange information about security issues in software, if everyone refers to the same vulnerability by the same number. The CVE ecosystem isn't perfect, and has been a bit turbulent over recent years. One cause of this is that the number of vulnerabilities has been increasing for a long time, and the organization that used to issue them became a bottleneck - it now delegates a lot of the work to others. One way it does this delegation is by working with "CVE Numbering Authorities". Basically, organizations can register as a numbering authority (CVE issuer) within a particular category of software. Sometimes this can be a single project (the Linux kernel recently became a CNA), but ideally it encompasses a range of related software. Which leads to the obvious suggestion... I believe it would be beneficial for the XSF to apply for CNA status, with the scope of issuing CVEs for software within the XMPP ecosystem. There are various benefits: - The XSF is already a hub for XMPP software developers, making discoverability and issuance easier for projects - Response times may be faster (due to the narrow scope, the XSF will naturally receive a far lower volume of CVE requests than generic CNAs such as MITRE) - The XSF has a history of coordinating vulnerability communication between projects when necessary. This has been very useful in the past, and it would help to bolster that activity. I think it would be sensible for us to discuss this. If there is positive consensus, I don't mind taking on the task of the application and any necessary processes. However for the operation of a CNA programme it would be good to have at least several trusted people willing to work on such a team. Further reading: - https://www.cve.org/PartnerInformation/Partner - https://nvd.nist.gov/general/cna-counting Regards, Matthew
Hey, Funny enough I was discussing CVEs at a conference last weekend, somewhat in relation to XMPP as well. The issue with CVEs is the amount of them, and the majority of them are so minor that you would have to be extremely unlucky for them ever to be exploitable. This doesn't mean you should ignore them, but it means you rarely know there is a major vulnerability within the spam of CVEs, take the Linux kernel for example, since parnering they have spammed so many CVEs that the average person is unable to keep up, and relies on the distro to handle it. I still think it would be useful, but could I recommend also having a security feed on the XSF website which maybe a small group of members can volunteer to be part of a security team, and they are responsible for documenting vulnerabilities of concern, and then maybe have another rss feed for CVEs which can be spammed with as many as needed. Therefore having the best of both worlds? Maybe it might be nice to have a security mailing list for the xsf too, which is low frequency unless there is a vulnerability of concern? Just some ideas :) Take care, -- Polarian Jabber/XMPP: polarian@icebound.dev
Hi Matt, Thanks for putting this proposal forward. I think it's a really interesting one, worth digging into properly. I can definitely see the upside. In particular, this could be a good signal of maturity for the XMPP ecosystem. It might also help with coordination around vulnerabilities, especially when issues span multiple implementations or touch protocol-level behavior. I think we're already doing some of that mostly informally, but having a clearer, more consistent "home" for XMPP-related CVEs seems like it could make things easier for both maintainers and security researchers. That said, I think there are a few important concerns to work through. The biggest one for me is the operational workload. Even if the number of CVEs is relatively small, this is still an ongoing responsibility that needs reliable attention and follow-through. I don't think it's realistic or healthy to assume this could just be handled by a single volunteer long-term (Matt or anyone else). If we go down this route, we'd really need a proper team and a sustainable setup around it, not just informal goodwill. Closely related to that is a liability / expectation shift. Even if CNA work is technically voluntary, it creates external expectations around response times, consistency, and correctness. That loops back into the workload issue and makes it even more important that we're honest with ourselves about what we can actually commit to. There's also a fair bit of complexity and ambiguity around scope. Is a generic library (like an XML parser used by a client) in scope? What about components that we don't consider to be XMPP project, but have some kind of XMPP-based interface? Forks? Abandoned projects? Lastly, I think following through on this would subtly change how the XSF governance stance is perceived: from being "just" a standards body to also acting as a security authority for part of the ecosystem. That's not necessarily bad, but it does mean we should be careful about transparency in how decisions get made. There may be neutrality concerns if the XSF is seens as 'judging' implementations. Overall I'm positive about exploring this further. I think a key missing piece right now is a clearer picture of what the operational model would actually look like in practice, and how tightly we define the scope so this doesn't turn into either overload or ambiguity. Also very interested in what others think, especially from people who've actually done CNA work or coordinated vulnerability disclosure before. Thanks again for putting this forward Matt - I think this could be very valuable to explore. Kind regards, Guus On Tue, Apr 28, 2026 at 8:43 PM Polarian via Members <members@xmpp.org> wrote:
Hey,
Funny enough I was discussing CVEs at a conference last weekend, somewhat in relation to XMPP as well.
The issue with CVEs is the amount of them, and the majority of them are so minor that you would have to be extremely unlucky for them ever to be exploitable. This doesn't mean you should ignore them, but it means you rarely know there is a major vulnerability within the spam of CVEs, take the Linux kernel for example, since parnering they have spammed so many CVEs that the average person is unable to keep up, and relies on the distro to handle it.
I still think it would be useful, but could I recommend also having a security feed on the XSF website which maybe a small group of members can volunteer to be part of a security team, and they are responsible for documenting vulnerabilities of concern, and then maybe have another rss feed for CVEs which can be spammed with as many as needed. Therefore having the best of both worlds?
Maybe it might be nice to have a security mailing list for the xsf too, which is low frequency unless there is a vulnerability of concern?
Just some ideas :)
Take care, -- Polarian Jabber/XMPP: polarian@icebound.dev
On Wed, 29 Apr 2026 at 19:09, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:
Hi Matt,
Thanks for putting this proposal forward. I think it's a really interesting one, worth digging into properly.
I can definitely see the upside. In particular, this could be a good signal of maturity for the XMPP ecosystem. It might also help with coordination around vulnerabilities, especially when issues span multiple implementations or touch protocol-level behavior. I think we're already doing some of that mostly informally, but having a clearer, more consistent "home" for XMPP-related CVEs seems like it could make things easier for both maintainers and security researchers.
That said, I think there are a few important concerns to work through.
The biggest one for me is the operational workload. Even if the number of CVEs is relatively small, this is still an ongoing responsibility that needs reliable attention and follow-through. I don't think it's realistic or healthy to assume this could just be handled by a single volunteer long-term (Matt or anyone else). If we go down this route, we'd really need a proper team and a sustainable setup around it, not just informal goodwill.
Agreed. The minimal feedback so far implies to me that there isn't significant interest in this proposal or in forming such a team.
Closely related to that is a liability / expectation shift. Even if CNA work is technically voluntary, it creates external expectations around response times, consistency, and correctness. That loops back into the workload issue and makes it even more important that we're honest with ourselves about what we can actually commit to.
There's also a fair bit of complexity and ambiguity around scope. Is a generic library (like an XML parser used by a client) in scope? What about components that we don't consider to be XMPP project, but have some kind of XMPP-based interface? Forks? Abandoned projects?
We would need to formally define the scope as part of the application process. I agree it's important to avoid ambiguity. A generic XML parser would not be in scope, as it does not implement any of the XMPP standards. An XML parser that is purpose-built for use in XMPP applications probably would be in scope. Thinking aloud, we could make this part of the existing software directory that we have (DOAPs, etc.).
Lastly, I think following through on this would subtly change how the XSF governance stance is perceived: from being "just" a standards body to also acting as a security authority for part of the ecosystem. That's not necessarily bad, but it does mean we should be careful about transparency in how decisions get made. There may be neutrality concerns if the XSF is seens as 'judging' implementations.
I think most people already don't see the XSF as "just" a standards body. Even if that is its primary function, we have done, and do, a bunch of extra stuff. I'm generally cautious about expanding the XSF's scope, however: - The XSF has played a role (multiple times) in coordinating cross-project security vulnerabilities. I think this has been extremely valuable in the past, even though it only happens infrequently. Having a bit more formality and documentation around this would be an improvement. - People have reported security issues to the XSF in the past, when issues affected multiple projects. The XSF doesn't have an official documented process to handle this, as I just mentioned. - This kind of thing needs a hub, and the XSF is undoubtedly such a hub for XMPP projects. We have a website, discussion infrastructure, and are well-connected to a large number of XMPP project developers (and users, such as operators).
Overall I'm positive about exploring this further. I think a key missing piece right now is a clearer picture of what the operational model would actually look like in practice, and how tightly we define the scope so this doesn't turn into either overload or ambiguity.
I believe it should take the form of a work team. The team members would need to be trusted (in some cases they would have privileged access to security issues before they are published). The charter would need to set expectations around how the security team would handle sensitive information, and about timelines, etc.
Also very interested in what others think, especially from people who've actually done CNA work or coordinated vulnerability disclosure before.
Me too.
Thanks again for putting this forward Matt - I think this could be very valuable to explore.
I think so too. But I'm also okay with dropping it if there isn't sufficient interest (both from projects which the CNA would cover, and from people who would consider participating on such a team). Regards, Matthew
On Wed, 6 May 2026 at 10:28, Matthew Wild <mwild1@gmail.com> wrote:
On Wed, 29 Apr 2026 at 19:09, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:
Hi Matt,
Thanks for putting this proposal forward. I think it's a really
interesting one, worth digging into properly.
I can definitely see the upside. In particular, this could be a good
signal of maturity for the XMPP ecosystem. It might also help with coordination around vulnerabilities, especially when issues span multiple implementations or touch protocol-level behavior. I think we're already doing some of that mostly informally, but having a clearer, more consistent "home" for XMPP-related CVEs seems like it could make things easier for both maintainers and security researchers.
That said, I think there are a few important concerns to work through.
The biggest one for me is the operational workload. Even if the number
of CVEs is relatively small, this is still an ongoing responsibility that needs reliable attention and follow-through. I don't think it's realistic or healthy to assume this could just be handled by a single volunteer long-term (Matt or anyone else). If we go down this route, we'd really need a proper team and a sustainable setup around it, not just informal goodwill.
Agreed. The minimal feedback so far implies to me that there isn't significant interest in this proposal or in forming such a team.
I certainly have interest in the XSF being a CNA. I think XMPP projects I'm involved in would appreciate it and use it. (I've not actually asked Guus about Openfire, but I would be keen, certainly). I'm not yet convinced there are enough people willing to do the work - indeed, I'm not sure I understand what the workload would be, yet, much less commit to it myself.
Closely related to that is a liability / expectation shift. Even if CNA work is technically voluntary, it creates external expectations around response times, consistency, and correctness. That loops back into the workload issue and makes it even more important that we're honest with ourselves about what we can actually commit to.
There's also a fair bit of complexity and ambiguity around scope. Is a generic library (like an XML parser used by a client) in scope? What about components that we don't consider to be XMPP project, but have some kind of XMPP-based interface? Forks? Abandoned projects?
We would need to formally define the scope as part of the application process. I agree it's important to avoid ambiguity.
A generic XML parser would not be in scope, as it does not implement any of the XMPP standards. An XML parser that is purpose-built for use in XMPP applications probably would be in scope.
Thinking aloud, we could make this part of the existing software directory that we have (DOAPs, etc.).
So we'd handle CVEs for projects for which we have the DOAP files on record? Seems sensible.
Lastly, I think following through on this would subtly change how the XSF governance stance is perceived: from being "just" a standards body to also acting as a security authority for part of the ecosystem. That's not necessarily bad, but it does mean we should be careful about transparency in how decisions get made. There may be neutrality concerns if the XSF is seens as 'judging' implementations.
I think most people already don't see the XSF as "just" a standards body. Even if that is its primary function, we have done, and do, a bunch of extra stuff. I'm generally cautious about expanding the XSF's scope, however:
- The XSF has played a role (multiple times) in coordinating cross-project security vulnerabilities. I think this has been extremely valuable in the past, even though it only happens infrequently. Having a bit more formality and documentation around this would be an improvement.
- People have reported security issues to the XSF in the past, when issues affected multiple projects. The XSF doesn't have an official documented process to handle this, as I just mentioned.
- This kind of thing needs a hub, and the XSF is undoubtedly such a hub for XMPP projects. We have a website, discussion infrastructure, and are well-connected to a large number of XMPP project developers (and users, such as operators).
I agree with all this. I think the benefits are easy to understand. I'd like to understand a bit more about the mechanics and operations.
Overall I'm positive about exploring this further. I think a key missing piece right now is a clearer picture of what the operational model would actually look like in practice, and how tightly we define the scope so this doesn't turn into either overload or ambiguity.
I believe it should take the form of a work team. The team members would need to be trusted (in some cases they would have privileged access to security issues before they are published). The charter would need to set expectations around how the security team would handle sensitive information, and about timelines, etc.
Also very interested in what others think, especially from people who've actually done CNA work or coordinated vulnerability disclosure before.
Me too.
Thanks again for putting this forward Matt - I think this could be very valuable to explore.
I think so too. But I'm also okay with dropping it if there isn't sufficient interest (both from projects which the CNA would cover, and from people who would consider participating on such a team).
Regards, Matthew
Agreed. The minimal feedback so far implies to me that there isn't significant interest in this proposal or in forming such a team.
I certainly have interest in the XSF being a CNA. I think XMPP projects I'm involved in would appreciate it and use it. (I've not actually asked Guus about Openfire, but I would be keen, certainly).
I'm not yet convinced there are enough people willing to do the work - indeed, I'm not sure I understand what the workload would be, yet, much less commit to it myself.
Well, I like the idea and would volunteer, but I don't understand what the workload would be either, so maybe I don't. I think some insights by people that actually did CNA work would be *very* helpful and most appreciated. -tmolitor
I second what Thilo says here. What would be the expected work and regular effort? Some more questions and thoughts: When do we see the XSF as CNA successful, when not? For example what means 'slow' currently? I remember Georg (?) intended years ago to list more of the present CVEs. How much of this this come close to what is expected here? See also this: https://xmpp.org/community/security-notices/ https://github.com/xsf/xmpp.org/tree/master/content/community/security-notic... If we start being a CNA, would that actually trigger "more" CVEs being reported? (--> growing effort?) Would we achieve new options and opportunities as organization being an CNA? Cheers, Eddie On 07/05/2026 21:12, Thilo Molitor wrote:
Agreed. The minimal feedback so far implies to me that there isn't significant interest in this proposal or in forming such a team.
I certainly have interest in the XSF being a CNA. I think XMPP projects I'm involved in would appreciate it and use it. (I've not actually asked Guus about Openfire, but I would be keen, certainly).
I'm not yet convinced there are enough people willing to do the work - indeed, I'm not sure I understand what the workload would be, yet, much less commit to it myself.
Well, I like the idea and would volunteer, but I don't understand what the workload would be either, so maybe I don't. I think some insights by people that actually did CNA work would be *very* helpful and most appreciated.
-tmolitor
participants (7)
-
Dave Cridland -
E.M. -
eevvoor -
Guus der Kinderen -
Matthew Wild -
Polarian -
Thilo Molitor