Calendar-based on-demand display of historic messages in a client that doesn't keep local history.Automatic history synchronization between multiple clients.The resulting protocol was designed to allow for the following primary 2.Īs this extension aims to make things easy for client developers, some research was made into the Multiple clients, to read the history of a MUC room, or to view old items in a pubsub node. Support local history storage, to synchronise conversation history seamlessly between This feature allows them to record conversations that take place on clients that do not It is a common desire for users of XMPP to want to store their messages in a central archive Including groupchat results in a user archive.For this you generally want projects with good docs, sane defaults and easy configuration. Security issues are more likely to be introduced through misconfiguration - accidentally having open account registration or an associated TURN server with an insecure setup. However I don't think there is anything much in the area of security to disqualify any of the server projects. I think your question is certainly an interesting one, and it was worth asking. I don't feel there are any major outliers here either.įor Prosody we have continuous unit testing, integration testing, and use code quality tools such as luacheck and semgrep to analyse the code for potential security issues before they get released. Nobody knows what software is secure or insecure until they find a flaw, so one of the main important questions is whether the project has a good track record of dealing with security issues well. I already gave some details in the other comment, primarily about the usefulness (or not) of CVE counts as a way to judge security.Īll servers you mentioned (Prosody, ejabberd, Openfire and Tigase) have some high-profile production deployments, so you can assume none of them are inherently insecure. All are written mostly/entirely in high-level languages with memory safety, for example. I don't think there is much to indicate that any of the active XMPP server implementations are more or less secure than others. That really makes the CVE count a poor measure of anything. So software having many CVEs could mean that the code has been more scrutinized, the team are more diligent about tracking security issues (even minor ones) or that the software really is full of security flaws. We requested a CVE for Prosody, while the other project fixed the issue without requesting a CVE. However there are, for example, cases where Prosody and other XMPP servers have been affected by the same issue. CVEs are a useful tool for anyone talking about security flaws in software. This is easy to see: software with no CVEs obviously does not mean it has no secure flaws (presently or in the past).įor Prosody specifically, we tend to lean towards requesting a CVE identifier for any security issue that we would urge people to upgrade for. I'm a Prosody developer, but just want to say that CVE count alone is not a good way to judge "how secure" software is. So I suppose there is plenty I can do versus a true public instance.īut I'm curious whether there is any history, or CVE count, or speed to patch, that is generally known by the community that preferences one server over the next? Do Openfire and Tigase get dinged for Java? Does Prosody's distro packaging make it a more sensible option for home hosting? Is there a difference in security posture between the enterprise intended and community options? Google turns up next to nothing about xmpp server breaches. No anonymous login or in-band registration, I can be aggressive with geo and other bad guy IP list blocks, and probably whitelist the limited number of clients connecting without too much consternation. Probably a difficult topic to define and maybe prejudiced slightly by recent java headlines, but I'm curious whether there is a useful framework for thinking about XMPP server security? My point of view is as a self-hoster using the home network's dmz for a non-federated, private chat service.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |