28 Apr
2026
28 Apr
'26
9:35 a.m.
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
28 Apr
28 Apr
12:42 p.m.
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
29 Apr
29 Apr
12:08 p.m.
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
6 May
6 May
3:28 a.m.
On Wed, 29 Apr 2026 at 19:09, Guus der Kinderen
<guus.der.kinderen(a)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
5:35 a.m.
On Wed, 6 May 2026 at 10:28, Matthew Wild <mwild1(a)gmail.com> wrote:
So we'd handle CVEs for projects for which we have the DOAP files on
record? Seems sensible.
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.
On Wed, 29 Apr 2026 at 19:09, Guus der Kinderen
<guus.der.kinderen(a)gmail.com> wrote:
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.
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
7 May
7 May
1:12 p.m.
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. 
10 May
10 May
2:09 p.m.
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-noti…
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:
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
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. 
12
days inactive
24
days old
7 comments
7 participants
participants (7)
-
Dave Cridland -
E.M. -
eevvoor -
Guus der Kinderen -
Matthew Wild -
Polarian -
Thilo Molitor