Openfire5.0.2
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 IgniteRealtime community is happy to announce a new release of its open source, real-time communications server server Openfire! Version 5.0.2 brings a number of stability improvements and bug fixes.
Notably, it addresses a recently identified security vulnerability, identifies as CVE-2025-59154. The issue allows for potential identity spoofing via unsafe Common Name attribute parsing. It is mostly applicable to what we perceive to be niche use-cases of Openfire. Please read the full security advisory for more information.
Openfire 5.0.2 is a bugfix release, with various bugfixes and improvements. Of particular interest to some will be the improvements made to the SystemD-based scripts (used in many Linux environments), which remove a few annoyances that were introduced in Openfire 5.0.1. 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 checksums for the binaries are:
4e907c615b3a19af0a1b5ab68ae24825b737496f9cf1715c9feafe8f909086da openfire-5.0.2-1.noarch.rpm
21271a6f22895852e50712236c45c7d213430171d5a3178474b8398f036ac07a openfire_5.0.2_all.deb
06794a12acdd8f23ca3c40fcd7af1677d8108b4b23bb72424c2751b30cfb3d14 openfire_5_0_2.dmg
c1e830b5e016d0bcff40005cc7bb14c846fe0ec26fc5a3fc967c30e5b6d2e356 openfire_5_0_2.exe
c84ca15cd470d3233add97c852c738eb373859dc9968ad34ec581725164c8114 openfire_5_0_2.tar.gz
98b5cf96326c668efb18cd9347b808a5ef85162b4a0b703aaf8e29d82cc6c727 openfire_5_0_2_x64.exe
8e09ca3dc7fb84b116ce95d10bfa3ff045708cdac4b23bd3d78ccf318e8742d8 openfire_5_0_2.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
Recently, Guus and and I co-authored XEP-0483: HTTP Online Meetings. I have just finished implementing the XEP across three Openfire plugins (ofmeet, galene and orinayo)
I also implemented it in the client olmeet plugins for both spark and conversejs.
So what’s the benefit?
Both spark and pade can now:
- auto-discover what audio/video conferencing service is available and configured in Openfire (jitsi, galene or broadcastbox),
- request for a web app URL and use it to
- invite others to the meeting. If their client supports XEP-0483, the web app will be opened in the client otherwise, it will be opened in the desktop web browser.
- fallback on a static base URL configured in client if their XMPP server does not yet support xep-0483.
For other release announcements and news follow us on Mastodon or X
Setting Up Slidge Gateway with Openfire for use with WhatsApp, Matrix, Telegram
2 months, 3 weeks agoSlidge is an XMPP gateway designed to connect your account to third-party chat networks like WhatsApp, Telegram, or Matrix. It acts as a bridge, allowing you to send and receive messages with all your contacts directly from your single, preferred XMPP client.
This guide provides instructions to configure an Openfire XMPP server to work with Slidge and the Slidge WhatsApp plugin as an example.
Openfire requires configuration in its Admin Console to allow external components like Slidge to connect and to grant them the necessary permissions for features like file transfers.
Prerequisites
Before you begin, ensure you have:
- A running and accessible Openfire server.
- Administrative access to the Openfire Admin Console.
- Root or sudo access to the Debian/Ubuntu server where you will install Slidge.
- The Slidge Debian repository added to your system, as per the official Slidge installation instructions (Installation - Slidge documentation).
This guide used the below install method.
Step 1: Configure Openfire Services
You must configure Openfire to accept the bridge connection and handle file transfers before you configure Slidge.
1.1. Install and Configure HTTP File Upload Plugin
Slidge requires a working XEP-0363 HTTP File Upload component to send and receive images, videos, and other files.
- Log in to your Openfire Admin Console.
- Navigate to Server → Plugins → Available Plugins.
- Find the plugin named “HTTP File Upload” and click the green + icon to install it.
- After installation, navigate to Server → Server Settings → HTTP File Upload.
- Ensure the box for “Enable HTTP File Upload” is checked.
Take note of the configuration. For a standard setup behind a reverse proxy, your public URL might be https://upload.your.domain while the internal service address is httpfileupload.your.domain.
We will use this internal address later.
- Click Save Settings.
1.2. Enable External Component Connections
This step allows Openfire to listen for incoming connections from bridges.
In the Openfire Admin Console, navigate to Server → Server Settings → External Components.
- Ensure the service is Enabled.
- Under the “Allowed to Connect” section, define your new WhatsApp bridge:
- Subdomain:
whatsapp(This will create the JIDwhatsapp.your.domain). - Shared Secret: Create a new, strong, random password.
- Copy this shared secret to a safe place. You will need it for the Slidge configuration.
- Click “Add”.
Your Openfire server is now ready for Slidge.
Step 2: Install and Configure Slidge
Now, on your server’s command line, we will install and configure the Slidge packages.
2.1. Install Slidge Packages
As per these instructions: slidge/debian: Debian (unofficial) package bundling slidge-based gateways. - Codeberg.org
2.2. Configure common.conf
This file contains settings shared by all your bridges.
- Edit the file:
nano /etc/slidge/conf.d/common.conf - Set the following parameters:
admins=admin@your.domain upload-service=httpfileupload.your.domain user-jid-validator=.*@your.domain server=localhost #port=5347 #(default slidge setting) port=5275 #(openfire default)
2.3. Configure whatsapp.conf
This file contains the settings for the WhatsApp bridge specifically.
- Create or edit the file:
nano /etc/slidge/whatsapp.conf
(I just didmv /etc/slidge/whatsapp.conf.example /etc/slidge/whatsapp.conf) - Add the connection details to match what you configured in Openfire:
# The XMPP address of your bridge component jid = whatsapp.your.domain # The shared secret you created in the Openfire admin console secret = PASTE_YOUR_SHARED_SECRET_HERE legacy-module=slidge.plugins.whatsapp
Step 3: Start and Verify Slidge
Enable and start the Slidge WhatsApp service:
sudo systemctl enable --now slidge@whatsapp
Check the logs to ensure it started without errors:
sudo journalctl -u slidge@whatsapp -f
Step 4: User Registration and Login
From your XMPP client (e.g., Conversations, Gajim), discover the services on your server. You should see the “WhatsApp” bridge listed.
Register with the service.
The bridge (whatsapp.your.domain) will be added to your contacts. Send it the message login or qr.
(I just started a conversation with a new chat to whatsapp.you.domain and typed help, it gives a list of commands, follow these e.g register)
You may see warnings in the Slidge log about “IQ privileges not granted” for pubsub and bookmarks (XEP-0356).
Troubleshooting: Fixing Permission Warnings (not yet implemented in Openfire so can’t fix this just yet)
For good luck I also did this at the end.
sudo systemctl restart openfire
sudo systemctl restart slidge@whatsapp
We are thrilled to announce the release of Openfire 5.0.0, the latest version of our popular open-source XMPP (Extensible Messaging and Presence Protocol) server. This release marks a significant milestone in our journey to provide a robust, scalable, and secure platform for real-time communication.
Openfire 5.0.0 comes packed with a host of new features, improvements, and bug fixes that enhance its performance, security, and usability. Here are some of the key highlights:
- Enhanced Security: We’ve made significant improvements to Openfire’s security infrastructure. These include the restoration and improvement of Certificate Revocation support, implementation of XEP-0421 for anonymous unique occupant identifiers in MUCs and updating Jetty’s embedded webserver for enhanced stability.
- Improved Performance: Openfire 5.0.0 is designed to handle larger loads more efficiently. We’ve optimized the server’s performance to ensure it can scale to meet the needs of your growing user base. Performance improvements include updating our network interaction layer with a recent version of Netty, optimizing database queries, and reducing duplicate code in multi-providers, resulting in a more efficient and responsive system.
- Plugin Updates: We’ve updated several of our core plugins to ensure they’re compatible with Openfire 5.0.0. This includes updates to our monitoring, clustering, and web-based chat client plugins.
- Bug Fixes and Improvements: We’ve squashed numerous bugs and added various features in this release, improving the overall functionality, stability and reliability of Openfire. Translations have been updated (and now include Turkish, Swedish and Italian), new group chat management features have been added, and parallelism when working with many federated domains has been improved, to name a few.
- Updated Java Requirement: Openfire requires Java 17 (or newer) to be installed.
Our deepest thanks go to NLnet Foundation for their invaluable support. With their funding and encouragement, we successfully implemented full IPv6 support and completed a robust security audit by Radically Open Security. NLNet’s mission to strengthen open and trustworthy internet infrastructure continues to make a real difference!
The changelog lists all of the changes that have been made.
We’re incredibly excited about this release and we can’t wait to see what you’ll build with Openfire 5.0.0. Whether you’re a developer looking to build a new real-time application, or an organization looking to improve your communication infrastructure, Openfire 5.0.0 has something for you.
As always, Openfire is free and open-source, so you can download it, use it, and modify it to suit your needs. We believe in the power of open-source software to drive innovation and we’re committed to continuing to support and develop Openfire.
Thank you to everyone who has contributed to this release, whether by submitting code, reporting bugs, or providing feedback. Your contributions are invaluable and we couldn’t do this without you.
You can download Openfire 5.0.0 from our website and check out our documentation to get started. We’ve also updated our community forums where you can ask questions, share ideas, and connect with other Openfire users.
Here’s to the future of real-time communication with Openfire 5.0.0!
For other release announcements and news follow us on Mastodon or X
I get regular requests and issues have been raised about upgrading the Jitsi meet code in the Openfire Pade plugin to the latest versions. Unfortunately, this task is much more difficult than it sounds.
Jitsi Meet has evolved a lot since the early days of WebRTC. It has moved from being a Java platform agnostic, XMPP compatible self-hosting application into a Linux cloud hosted service.
The current code still depends on our Smack project for the XMPP client, but it uses Prosody as the XMPP server with quite a few extensions and modules coded in Lua which need to be ported to Java. Apart from not having time to work on it, I have also lost the motivation to step up to the challenge as I am more interested in using WHIP and WHEP with XMPP.
Nevertheless, an issue can round last week requesting for support of AV1 codec. This sparked enough motivation for me to spend my Easter holidays trying one more time to make the upgrade happen. The bad news is that I failed yet again, but the good news is that I was able to update the existing code to support AV1. Please note that codecs have pros and cons. VP9 is probably the best all rounder. H264 is best with devices that have hardware encoders and AV1 handles low bandwidth the best.
Openfire Pade plugin version 1.8.4 now supports the AV1 codec. You get the best results with P2P calls. As it is it more CPU intensive than VP9, you make get lower frame rates on low-spec servers. The latest Jitsi code has a lot more improvements and if you really need AV1 with many participants, seriously consider deploying the Jitsi Meet self-hosted instance in a container or VM.
As always, your instance of Openfire should automatically make available to update. Alternatively, you can download the new release of the plugin at the Openfire Pade plugin’s archive page.
For other release announcements and news follow us on Mastodon or X
Schwach in "
G.orlando in "
Rudi in "
Tago in "
Harald Bergmann in "