[Members] Re: Proposal: XSF as a CVE Numbering Authority (CNA)

On Wed, 29 Apr 2026 at 19:09, Guus der Kinderen <guus.der.kinderen(a)gmail.com> wrote: interesting one, worth digging into properly. 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. 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.

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

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

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. actually done CNA work or coordinated vulnerability disclosure before. Me too. 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