Openfire5.1.0
Openfire is a real time collaboration (RTC) server licensed under the Open Source Apache License. It uses the only widely adopted open protocol for instant messaging, XMPP Openfire is incredibly easy to setup and administer, but offers rock-solid security and performance.
The Ignite Realtime community is pleased to announce the release of Openfire 5.1.0, the latest version of our open-source XMPP real-time communication server!
Since the 5.0.0 release, now over 11 months ago, we’ve kept the 5.0.x branch stable and maintained, but have also been working on the next set of bigger changes. With this release, those have (finally - sorry for the wait!) been made available. If you’ve been following along in the chat or forums you might have seen pieces of it being put together: the channel binding work, the DNS improvements, the new database experiments have been in the works for quite some time, and have seen quite some discussion and collaboration. Let me give you an overview of what is included with the 5.1.0 release.
The biggest theme is security. With generous support from NLnet Foundation 
we’ve implemented SASL channel binding (OF-2694, OF-2879), which ties authentication to the underlying TLS connection and closes the door on a class of man-in-the-middle attack that has been observed against real XMPP servers in the wild. While we were in that part of the codebase, we also audited the encryption utilities, and found a few things worth fixing. A hardcoded AES initialisation vector (OF-3074), a single-round unsalted SHA-1 used for Blowfish key derivation (OF-3075), CBC-mode padding that was susceptible to oracle attacks (OF-3077), and timing side-channels in SCRAM-SHA-1 authentication (OF-3257, OF-3258). None of these were discovered under active exploitation, but they’re the kind of thing that shouldn’t be there, and now they’re not. We’ve also tightened up certificate identity handling (OF-3122), SASL mechanism enforcement (OF-3273), and login throttling (OF-3262), and added proper support for trusted reverse proxy configuration (OF-3260, OF-3261).
There’s also a performance fix that deserves a mention. Community members reported this issue in the PubSub functionality: after investigation, we found a method in the persistence code doing a full linear scan of every node in memory for each row it processed from the database (OF-3196). That’s O(n²), which is fine at small scale and quietly catastrophic at large scale. On a deployment with around 600,000 pubsub nodes it was causing startup times of over two hours. The fix was not much more than a one-line change. If you’ve ever accepted a very long Openfire startup as just a fact of life, this release is for you. Alongside that, blocking operations have been moved off Netty’s event loop threads (OF-3176) to improve responsiveness under load, and we’ve upgraded to Netty 4.2 (OF-2957).
5.1.0 also brings some ecosystem-related updates to Openfire. Java 25 is supported (OF-3210), and three new databases join the supported lineup:
- MariaDB (OF-3239), which many operators have been running as a MySQL stand-in for years anyway;
- Firebird (OF-3237), for the on-premise environments where it’s been quietly doing the job for a long time; and
- CockroachDB (OF-3238), for distributed and cloud-native deployments.
Support for these has not landed in most plugins yet, but we’ll work on that in the coming time. In the mean time, please try them out, and tell us what you think!
On the protocol side, Openfire now handles XEP-0398 (avatar synchronisation between XEP-0084 and vCard-based avatars, OF-2034), and provides a proper API for Service Discovery Extensions (OF-3188) so plugins no longer need to intercept IQ stanzas to enrich discovery responses. For operators, there’s a new diagnostics page for failed S2S connections (OF-3037), a UI for managing DNS overrides (OF-3244), configurable rate limiting for incoming connections (OF-3170), and a Docker healthcheck (OF-3184).
The bug fix list is long, but a few stand out: orphaned S2S routes that caused silent packet loss (OF-3193, OF-3201); encrypted properties being silently stored in plaintext after XML-to-database migration (OF-3296); plugin reload failures on Windows (OF-3208); and chatroom subjects not being delivered on join in certain conditions (OF-3131).
The full changelog lists 121 items resolved!
You can obtain Openfire 5.1.0 for your platform from its download page. The sha256sum values for the release artefacts are:
0686b30d4fb5e6f7c43bff7071ac425e45a19bbd528e301df065ef8d60355ef5 openfire-5.1.0-1.noarch.rpm
90b21993ba65d98357154183fd12e938547e68cbc59301f69b8506f483580269 openfire_5.1.0_all.deb
5fff05c4a689ae3431d5578f594e37cf7a68a2c0f36380b76d132d79217913c0 openfire_5_1_0.dmg
f72d766957eb09bedcbe8a5f64c38db85684af62bf5282534a162385f7b449ed openfire_5_1_0.exe
0cc848b56339f07fdcbcbb92dea73a35c00661576d68f1908640ecf7c3b6febc openfire_5_1_0.tar.gz
a830b0451770d6c8f8db81b3584299f54c48ca8c6d4bf42671325fef0b74c878 openfire_5_1_0_x64.exe
8b3f30505b3996b4b8261a99710ac2387131dac9b5a75fbbf65e9e3419aa22f5 openfire_5_1_0.zip
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
As we’re preparing the upcoming Openfire 5.1.0 release, I’ve been spending a lot of time looking at parts of the codebase that have been around for a long time.
Some of them date back to assumptions that were perfectly reasonable when Java 5 was current, IPv6 was still considered “future tech”, Docker didn’t exist yet, and “cloud-native” wasn’t a phrase anyone but meteorologists used.
Yet somehow, Openfire deployments that started in those days are still running today.
That got me wondering:
What’s the oldest Openfire deployment that you still run?
Not necessarily the oldest version (although I’d love to hear that too), but the oldest continuously running installation, the oldest surviving user database, or perhaps the weirdest setup that somehow still works despite years of upgrades, migrations and changing infrastructure.
I suspect there are Openfire instances out there that have survived datacenter migrations, moved from physical hardware to virtual machines to containers, switched databases more than once, and outlived several generations of administrators. Some probably still contain configuration decisions that nobody fully understands anymore. Is anyone still running Wildfire? Jive Messenger?
Honestly, I love those stories from the trenches. The odd workarounds, the “temporary” fixes that became permanent infrastructure, the upgrade that everyone expected to fail but somehow didn’t, or the deployment that quietly kept running for a decade without anyone thinking much about it.
One of the things I appreciate most about infrastructure software is that success often becomes invisible. If a messaging server quietly keeps working for ten years, nobody talks about it. But that kind of stability is actually a huge achievement (both for the software and for the people operating it). I think that’s something we, as a community, can be genuinely proud of.
For Openfire 5.1.0, we’ve been modernizing quite a few internals:
- support for Java 25
- upgrades to Netty 4.2 and various database drivers
- improvements around reverse proxies and DNS handling
- clustering improvements
- security hardening
- performance fixes for larger deployments.
While doing that work, we constantly try to balance modernization with compatibility for long-running installations. That balancing act becomes much easier when we understand how people actually deploy and operate Openfire in the real world, which, apart from simply wanting to hear your stories, is another reason for me to ask this question.
So: I’d love to hear your stories! How old is your deployment? What version did you start with? What infrastructure changes has it survived over the years? Are there plugins or integrations you absolutely depend on? What operational lessons have you learned?
And perhaps most importantly: what surprised you most about running Openfire long-term?
I’m hoping this thread becomes a collection of deployment stories, operational lessons, and perhaps a bit of Openfire history.
Looking forward to hearing your stories!
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
The Ignite Realtime community is pleased to announce a new release of Openfire, version 5.0.5. The full changelog has more details with the highlights being bug fixes and bundled library updates whilst we continue to work on an upcoming 5.1.0 feature release.
You can obtain the new version of Openfire for your platform from its download page. The sha256sum values for the release artifacts are:
4ba9b6476efefc54378c0fd4a2a402177fd94bc11512354db887eb446f37f211 openfire-5.0.5-1.noarch.rpm
3a870ef09415f3bf2eac315ac826b59997eba6bcc38a1eb3740856ff16ffc11c openfire_5.0.5_all.deb
94d3a8a159a68fdff17394c415d3ce1feb557fb8ef0618a883180f668a359cc2 openfire_5_0_5.dmg
bbc4c1147ff1a4d8740a5e12929e650dc04e3c7a6c765ff13855da48c16f980a openfire_5_0_5.exe
50028a20587ea9d6b5bcc8260ca626e022d223b39748ffe7b9851d9b344dba6b openfire_5_0_5.tar.gz
649f3b14a5403275780a2344b2d575f163a2e182eefa9c4978bd325cbf7486d5 openfire_5_0_5_x64.exe
49edd9873a84d2f6b19c24d360ac964ea9180753f6dff4355d75be3943e20817 openfire_5_0_5.zip
For those of you that enjoy metrics, here’s an accounting of 5.0.4 release artifact downloads.
| Name | OS | Downloads |
|---|---|---|
| openfire_5_0_4_x64.exe | Windows 64bit Launcher | 7,156 |
| openfire_5_0_4.exe | Windows 32bit Launcher | 4,963 |
| openfire_5.0.4_all.deb | Linux Deb | 4,455 |
| openfire_5_0_4.zip | Zip binary | 4,013 |
| openfire_5_0_4.tar.gz | Tar.gz binary | 3,526 |
| openfire-5.0.4-1.noarch.rpm | Linux RPM | 3,232 |
| openfire_5_0_4.dmg | Mac | 2,768 |
| Total | – | 30,113 |
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
I have recently started experimenting with adding support for three additional databases in Openfire: MariaDB, Firebird and CockroachDB.
This work is still exploratory. Before committing to this direction, I would like to get a better understanding of whether this is actually valuable to the Openfire community.
I have prepared initial pull requests for each database:
- MariaDB: https://github.com/igniterealtime/Openfire/pull/3240 (OF-3239 in our issue tracker)
- Firebird: https://github.com/igniterealtime/Openfire/pull/3241 (OF-3237 in our issue tracker)
- CockroachDB: https://github.com/igniterealtime/Openfire/pull/3243 (OF-3238 in our issue tracker)
These are not production-ready, but intended to validate feasibility and surface any obvious issues.
Why these databases?
MariaDB is widely used as a drop-in replacement for MySQL. Although Openfire supports MySQL, MariaDB is not explicitly treated as a first-class option. Given how often it is used in practice, formal support could provide more confidence for administrators.
Firebird represents a more niche but still relevant ecosystem. It is commonly found in long-lived, on-premise systems where changing the database is not realistic. Supporting it could make Openfire easier to adopt in those environments.
CockroachDB targets modern, distributed deployments. With its PostgreSQL compatibility and focus on resilience and scalability, it could make Openfire more attractive for cloud-native and multi-region setups.
Trade-offs
Supporting additional databases comes with a cost: more code paths, more testing, and more long-term maintenance. The key question is whether the added flexibility justifies that complexity.
Feedback wanted
Before taking this further, I would really appreciate feedback from the community:
Are you using (or considering) MariaDB, Firebird or CockroachDB with Openfire? Would official support influence your deployment decisions? Do you see this as valuable, or as unnecessary complexity?
Please share your thoughts on the pull requests or through the usual community channels!
For other release announcements and news follow us on Mastodon or X
The Ignite Realtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.4 continues our effort to provide stable 5.0.x series releases whilst we finalize work on an upcoming 5.1.0 release. Please refer to the full changelog for more details.
You can obtain the new version of Openfire for your platform from its download page. The sha256sum values for the release artifacts are:
c49add8f50999b2d7fcdd8960bc7d70bf59eb95d12daedf92902e4b034c1c737 openfire-5.0.4-1.noarch.rpm
14d22bef24fb01770f51c655c8b3b54207125b1b70641175d8ad25b585e6332a openfire_5.0.4_all.deb
ddd40e0bac4c4fae0678b6df4fd5ad28f77af50fd530e3327326f3b488f16ae4 openfire_5_0_4.dmg
8c2fcb27f9afe01b79d59f7bf0736b21cdb72b5464de25a183b596329e351099 openfire_5_0_4.exe
01c7314268d87b1f8eee0677bb89656f12a082e6461b207d3955f5d9632e2f78 openfire_5_0_4.tar.gz
13b579672b2ce238934aa919cd968636c0f5c8afda5aeb3aec08d60feca35df4 openfire_5_0_4_x64.exe
05b9e5fa976202ef97d183177f6de699cf68bf0cfd422f721a4c8dc5676c1612 openfire_5_0_4.zip
For those of you that enjoy metrics, here’s an accounting of 5.0.3 release artifact downloads.
| Name | OS | Downloads |
|---|---|---|
| openfire_5_0_3_x64.exe | Windows 64bit Launcher | 12,407 |
| openfire_5_0_3.exe | Windows 32bit Launcher | 8,269 |
| openfire_5.0.3_all.deb | Linux Deb | 8,113 |
| openfire_5_0_3.zip | Zip binary | 6,747 |
| openfire-5.0.3-1.noarch.rpm | Linux RPM | 5,811 |
| openfire_5_0_3.tar.gz | Tar.gz binary | 5,773 |
| openfire_5_0_3.dmg | Mac | 4,646 |
| Total | – | 51,766 |
We’d love to hear from you! Please join our community forum or group chat and let us know what you think!
For other release announcements and news follow us on Mastodon or X
WebGreg in "
martdim in "
ramada in "
Nomak in "
Tony Burtovoy in "