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(a)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(a)icebound.dev