XSF Discussion - 2022-09-28

Hi Ge0rG, what was the last status of this security/cve extraction?

emus: it was considered a bad marketing idea to have a central list of the xmpp shortcomings

Ah I remember. Well is it that much or is it that in general? I mean, each software has that problems I believe?

lets look at the others https://www.opencve.io/cve?vendor=matrix

There matrix is a vendor though, XMPP isn't and neither is the XSF

ie https://www.opencve.io/cve?vendor=gajim

https://www.opencve.io/cve?cvss=&search=xmpp well yes, but you get an answer

> Ge0rG: > 2022-09-28 05:46 (GMT+02:00) > emus: it was considered a bad marketing idea to have a central list of the xmpp shortcomings is that the general opinion around here?

btw

I could see it in only the context of maybe server operators. But then i think there are better sources for that.

emus: does IETF have a list of CVEs related to RFCs ?

I think if they don't then we shouldn't

Maybe they should if they don't have

Good then we should wait for them to do it then just filter the ones from the XMPP RFC :)

> "Malicious key backup" – the above 'trusted impersonation' bug in matrix-js-sdk (and derived SDKs) could be used by a malicious homeserver admin to add a malicious key backup to the user's account under certain unusual conditions in order to exfiltrate message keys.

I don't think the IETF is a fair analogy. The XSF has always been more about the ecosystem and implementations than the IETF (I mean, it used to be called the Jabber *Software* Foundation). It is also much narrower in scope.

Wow @ matrix, it's not a protocol bug, it's just e2e that allows your server admin to request a copy of your keys

This is an argument against OX style key sharing by the way