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