Ignite Realtime is the community site for the users and developers of Jive Software's open source Real Time Communications projects. Your involvement is helping to change the open RTC landscape.
We have started to experiment with an online tool that facilitates the process of translating Spark and Openfire. Both already have a bunch of translations, but none are complete.
I’m looking for people wanting to test the tool and/or provide translations. The aim is to make providing translations become so easy that little technological know-how is required.
If you’re interested, please sign up to Ignite Realtime localization | Transifex and let me know what you think!
Some of you might already have followed along with the discussion on this in the open_chat chatroom, but: the Ignite Realtime community now has its own Mastodon service at toot.igniterealtime.org! This service is graciously sponsored by Free Solutions Sàrl - a big thank you to Claude and his team!
The idea is to have a Mastodon service with accounts from like-minded people with regards to open source / open standards real time collaboration. That way, both our local as well as federated timelines should become more applicable to us, as the users of this service, as compared to one of the larger, generic servers that are out there. Also, decentralizing by moving away from some of those gigantic services is a Good Thing©®!
We are inviting our community members to join toot.igniterealtime.org! If you don’t have a Mastodon account yet, or if you want an additional one, or want to migrate your existing account, please join us!
At least for now, this server is not accepting public sign-ups. While we are gaining experience with running a Mastodon service, we will limit new accounts to people from the community that we recognize. This will largely be based on the trust levels that software running our forum is assigning to people.
When you sign up on our Mastodon service, please use the same mail address that you used to sign up to our forum, so that we can cross-reference who’s who. It helps if you fill out your forum username in the answer to the “Why do you want to join?” question that’s part of the application. The approval process is manual, so please allow for some time for that to happen. If you think that we’ve missed your request (Mastodon doesn’t always send out notifications, it appears), please let us know by reaching out in the forum, or in the open_chat chatroom!
We are looking forward to hearing from you in the Fediverse!
The Ignite Realtime community is happy to announce the release of Spark 3.0.1 version.
This release contains mostly fixes. macOS now uses the default FlatLaf LaF. The user can also choose the type of tabs “scroll” as in Spark 3.0.0 or “wrap” as in Spark 2.X. See screenshot below. And also for some users, Spark not saved history.
To do this, go to File → Preferences → Chat
Full list of changes can be found in the changelog .
We encourage users and developers to get involved with Spark project by providing feedback in the forums or submitting pull requests on our GitHub page.
You can download Spark from the Downloads page. Below are the sha256 checksums:
55b5efaaaa59e661d7e94b0f4168d37d383cd521c8a954a36fa7943339e197f6 *spark_3_0_1-64bit.exe 5a6c2a10df14d1892216de188e1c2558ebd5f05ff4529f00fcb65ce30f2d4bce *spark_3_0_1-64bit.msi 172b6fca86b43c370a7de1c7e2c05d6581341e656474b7bea868f5927804efb8 *spark_3_0_1-arm.exe b837ce77016e2a438e1dd9f2ef2d7752985b777be8dd4152296d7e48fc285fbb *spark_3_0_1-with-jre.dmg bf9ba305aaf5e763eca5fc8332c73b5c155b49e03a28c5352777aa577bf66a41 *spark_3_0_1-with-jre.exe a496956254bd65a87f65a266cf50e4b6c6ad71a371565ba91dc1e236cee39b8c *spark_3_0_1-with-jre.msi 02001b7c17780c7aeb6d37f66efe898d291043fbbc201bb958f8af9b3b9abf52 *spark_3_0_1.deb 7aa635154a4d34c401e871641626e7db3e48938d48f62f64d023c77d10fc1e89 *spark_3_0_1.dmg 41ce2b95c0e43808359943f899a34054a72b570efd1183ff41848b79e26f2f38 *spark_3_0_1.exe 5afdc4b1ab3ae6b77349b9d3e86003179af6b47b960535544843dd8542fd37f0 *spark_3_0_1.msi 1e0f51db2d836ef3041ce354a7c7bbeec3b220781e8750cf1e027ad5ecf50cbc *spark_3_0_1.rpm ca35cb357f2e928db638f5eac2066f364b5c4af23bd558df1e6c18ae3854e6b7 *spark_3_0_1.sh ace373ad59d8fb928d6841a61ac06353a05c4374d9d30df86b875b0e77e9bbc4 *spark_3_0_1.tar.gz
The fantastic folks behind Jitsi have discovered a Denial of Service (DoS) vulnerability in Smack (JSA-2022-0002, JSA-2022-0003), which is possible if a combination of Smack components is used. The root of the vulnerability is interesting because it is due to a countermeasure against DoS attacks, namely FEATURE_SECURE_PROCESSING of the Java API for XML Processing (JAXP).
The DoS is possible because the older XMPPTCPConnection implementation of Smack parses the XMPP stream as one large XML document. Suppose the connection instance uses a parser where FEATURE_SECURE_PROCESSING is enabled. In that case, it is easy for an attacker to craft a stanza that triggers one of the various limits imposed by FEATURE_SECURE_PROCESSING, causing an exception, leaving the parser in an unrecoverable state, and closing the connection.
This vulnerability was relatively recently introduced in Smack with the addition of the support for JAXP’s Streaming API for XML (StaX) parser. Historically, Smack only used XPP3 as XML pull parser. The default implementation of XPP3 is a fast, lightweight, and, to the best of our knowledge, secure parser. XPP3 is used, for example, by Android. However, with version 4.4.0 (SMACK-591), Smack gained support for using Java’s Streaming API for XML (StAX) in addition to XPP3, to facilitate code-reuse on Java SE platforms and avoiding the XPP3 dependency.
So this DoS is possible if the XMPP connection is of type XMPPTCPConnection and if the Smack connection instance uses a StAX parser for XMPP parsing.
On a related note, Smack’s newer modular connection architecture is not affected by this, because it splits the individual top-level XMPP stream elements and parses them as standalone document. The splitting is done very early in the input processing step by XmlSplitter (of jxmpp), which also enforces size limits for the XML elements. Therefore, the DoS is not possible over connections that are established via Smack’s modern ModularXmppClientToServerConnection.
If you are affected, then the following countermeasures are possible:
Option A has the drawback that it is only possible to relax the limits globally. That is, it will affect XML processing regardless if Smack or some other component performs it. If you still want to go down that route, then
System.setProperty("jdk.xml.entityExpansionLimit", "0") System.setProperty("jdk.xml.maxOccurLimit", "0") System.setProperty("jdk.xml.elementAttributeLimit", "0") System.setProperty("jdk.xml.totalEntitySizeLimit", "0") System.setProperty("jdk.xml.maxXMLNameLimit", "524288") System.setProperty("jdk.xml.entityReplacementLimit", "0")
We have now released version 1.2.0 of the HTTP File Upload plugin!
This plugin adds functionality to Openfire that allows clients to share files, as defined in the XEP-0363 ‘HTTP File Upload’ specification.
This release primarily enhances functionality when running in an Openfire cluster. All changes can be reviewed in the changelog for this release of the plugin.
As always, your instance of Openfire should automatically display the availability of the update. Alternatively, you can download the new release of the plugin at the HTTP File Upload plugin’s archive page.