Nouveau plugin AVHIRAL Secure OMEMO pour Spark V4.4.6 – Chiffrement de bout en bout intégré

Bonjour à tous,

Depuis plusieurs semaines, je travaille sur un nouveau plugin permettant d’ajouter le chiffrement OMEMO (XEP-0384) directement dans le client Spark.

L’objectif n’était pas simplement d’ajouter une couche de chiffrement, mais de proposer une intégration native dans l’interface de Spark, sans ouvrir une seconde fenêtre de discussion.

Aujourd’hui, le projet est suffisamment avancé pour être présenté à la communauté.

Fonctionnalités actuelles

  • :locked: Chiffrement OMEMO de bout en bout.

  • :speech_balloon: Intégration directement dans les conversations Spark.

  • :locked_with_key: Cadenas d’activation OMEMO dans chaque discussion.

  • :magnifying_glass_tilted_left: Découverte automatique des appareils OMEMO.

  • :satellite_antenna: Publication automatique des appareils.

  • :handshake: Établissement automatique des sessions OMEMO.

  • :outbox_tray: Chiffrement automatique des messages.

  • :inbox_tray: Déchiffrement automatique des messages reçus.

  • :white_check_mark: Compatible Spark 3.0.2.

  • :white_check_mark: Basé sur Smack 4.4.6.

  • :white_check_mark: Tests d’interopérabilité réalisés avec Monal (iOS).

L’utilisateur continue d’utiliser Spark normalement. Lorsqu’OMEMO est activé, les conversations deviennent simplement chiffrées.

Distribution

Le plugin est disponible sous forme de binaire sur GitHub.

Je tiens également à remercier les équipes d’Ignite Realtime ainsi que les développeurs de Smack pour le travail réalisé autour de Spark et de l’écosystème XMPP.

Merci d’avance à toutes les personnes qui prendront le temps de tester le plugin et de partager leurs retours !

LinkedIn:

https://www.linkedin.com/company/avhiral

David Pilato
Directeur Général – AVHIRAL
Cybersecurity • Secure Communications • XMPP Security

avhiral-omemo.jar (1,4 Mo)

1 Like

Merci David !

C’est une excellente nouvelle ! La demande de fonctionnalité SPARK-1866 est enregistrée dans JIRA et si vous l’avez déjà implémentée, ce serait formidable.

Pourriez-vous partager le code source du dépôt GitHub ? Si vous acceptez de le publier sous licence Apache 2, je pourrai intégrer le plugiciel à la distribution Spark.

L’application aTalk pour Android est également basée sur la bibliothèque Smack et intègre la dernière version d’OMEMO. Son auteur a soumis de nombreuses demandes d’extraction à Smack, mais aucune n’a encore été fusionnée (Issues · igniterealtime/Smack · GitHub). J’aimerais donc copier et migrer le code d’aTalk pour la prochaine version.

La prochaine version de Spark nécessitera Java 11 comme prérequis minimal et Smack 4.5. Les anciens plugiciels ne seront donc pas compatibles. Si vous pouvez partager le code, je pourrai le migrer vers la dernière version de Spark.

English

Thank you, David!
This is a great news, the JIRA has the feature request SPARK-1866 and if you already implemented it then this would be just great.
Could you share source code in the repository on GitHub? If you are fine to make it under the Apache 2 license then I can include the plugin to the Spark distribution.

The aTalk for Android is also based on the Smack library and it has the latest OMEMO implemented. Its author sent many PRs to the Smack but non of them were merged yet Issues · igniterealtime/Smack · GitHub
So I wanted to copy and migrate the code from the aTalk in next release.

The upcoming Spark version will use the Java 11 as minimal requirement and the Smack 4.5 so old plugins won’t work. If you can share the code then I can migrate it to the latest Spark.

Je prépare un autre plugin pour utiliser spark en téléphone & visio, mais assez complexe.

J’ai mis à jour le GitHub l’archive ZIP (sources) :

Le plugin fonctionne en communication de Spark vers un téléphone avec l’appli “Conversations” sur Android, ou “Siskin IM” sur Iphone, en faite le chiffrage OMEMO est synchronisé.

Merci beaucoup!

J’ai brièvement vérifié à quel point il serait compliqué de mettre à niveau le plugiciel vers les dernières versions de Smack et Spark. On dirait que ça va prendre plus d’efforts que prévu. Je le ferai donc après avoir terminé les tâches en cours et la sortie de la prochaine version de Spark. Le problème, c’est que la prochaine version m’a déjà pris plus de temps que j’y avais consacré. Donc je ne peux même pas imaginer maintenant quand j’aurai le temps pour ça.

Pour l’instant, j’ai ajouté votre plugiciel au référentiel Spark lors d’un brunch séparé avec des modifications mineures pour adopter la nouvelle API Spark et le nouveau style de code.

Merci encore !

In English

I briefly checked how complicated it will be to upgrade the plugin to the latest Smack and Spark. It looks like it will take more efforts than I expected. So I’ll do that after finishing current tasks and release of the next version of the Spark. The problem is that the upcoming release already eated more my time than I dedicated. So I can’t even imagine now when I’ll have a time for this.

For now I added your you plugin to the Spark repository on a separate brunch with minor changes to adopt the new Spark API and code style.

1 Like

First of all, welcome to the Ignite Realtime community, @avhiral and thank you for taking the time to share your work. It’s great to see people investing in modern security features for Spark. OMEMO support has been requested by users for a long time, so it’s encouraging to see progress in this area.

That said, I’d like to clarify a few things from the perspective of the community and project governance.

From your announcement, it isn’t entirely clear whether you’re presenting a commercial/independently maintained plugin, or whether your intention is to contribute this work to the Spark open source project. Could you clarify your goal? Both are perfectly valid, but they lead to very different conversations.

I also want to caution against distributing binaries directly through the forum. While there is some historical precedent for this in our community, I don’t think it’s a practice we should encourage - particularly for software that provides security or cryptographic functionality. Users should be able to evaluate a project’s provenance, documentation, licensing and source before deciding to install it. In general, I’d much rather see announcements link to a project’s home page or source repository than directly to downloadable binaries.

If your intention is to contribute this work to Spark, then it will naturally need to follow the project’s normal contribution process. We cannot incorporate closed-source contributions into our Apache-licensed projects. Without access to the source code, the community has no way to review the implementation, verify its functionality, assess its quality, evaluate its security, or even determine whether the licensing is compatible with our projects. This is especially important for cryptographic functionality, where transparency and peer review are essential.

OMEMO deserves particular care in this regard. Implementations often rely on components that have licensing implications, and we’d need to understand those dependencies before any integration into an Apache project could even be considered.

On the other hand, if your intention is to offer this as an independently maintained commercial or proprietary product, that’s absolutely a valid approach as well. Ignite Realtime has long supported an ecosystem of companies that build services and products around our software. In that case, I’d encourage you to consider having AVHIRAL listed on our Professional Service Providers page. That gives your company visibility to organizations looking for commercial support around Ignite Realtime technologies, while keeping a clear distinction between community-maintained open source projects and independently developed products.

Again, thank you for sharing your work. I look forward to learning more about your intentions for the project, and I hope we can find the appropriate way for it to fit into the Ignite Realtime ecosystem.

1 Like

Hello @guus,

Thank you very much for your thoughtful feedback and for taking the time to review my work.

My primary goal with this project is to contribute to the Ignite Realtime community by bringing modern OMEMO support to Spark. This feature has been requested for many years, and I wanted to provide a practical implementation that already works with the main OMEMO-compatible XMPP clients, including Conversations on Android and Siskin IM on iOS.

As you have already noticed, the GitHub repository contains both the complete source code and the compiled binaries. The binaries are provided simply as a convenience for users who want to try the plugin quickly, while the full source code is available for review, compilation and auditing.

The plugin is currently developed and maintained independently by AVHIRAL. Our objective is naturally to contribute useful improvements to the community, while also introducing AVHIRAL and our expertise in cybersecurity, secure communications and XMPP technologies.

I am very pleased to hear that you have already started adapting the plugin to Spark’s upcoming architecture. I completely understand that migrating to Java 11 and Smack 4.5 represents a significant amount of work, and I sincerely appreciate the time you have already invested in reviewing the project.

On my side, I am currently working on additional features, including a Jingle-based audio and video calling plugin, with the goal of bringing modern voice and video communication capabilities directly into Spark.

Finally, you mentioned the Ignite Realtime Professional Service Providers page. I would be delighted if AVHIRAL could be listed there. We provide professional services around XMPP infrastructures, secure communications and cybersecurity, and we would be pleased to become a more active part of the Ignite Realtime ecosystem.

Thank you again for your warm welcome and for the time you have dedicated to this project. I hope this will be the beginning of a productive collaboration with the Ignite Realtime community.

Best regards,

David Pilato
CEO – AVHIRAL

1 Like

Veuillez noter que le Spark avait déjà des appels audio. Ils étaient désuets et tout simplement désactivés lors de la construction. Cette fonctionnalité peut être restaurée, mais je ne suis moi-même pas familier avec les appels audio.

English

Please note that the Spark already had audio calls. They were obsolete and just disabled from build. This functionality can be restored but I myself not familiar with audio calls.

Thanks for clarifying that this is a proprietary plugin.

I think that distinction is important, as it wasn’t entirely clear to me from the original announcement. There is absolutely nothing wrong with building commercial or proprietary software around Ignite Realtime projects - we’ve always encouraged an ecosystem of companies doing exactly that.

However, it’s equally important to distinguish those products from the community-maintained open source projects.

If the intention is to offer this as an independently maintained product, I’d encourage making that more explicit in both the forum post and the repository. At present, the repository mainly serves as a distribution point for binaries and archived files, rather than a source code repository, while the README explains that the implementation itself is proprietary. Making that distinction clear upfront would help avoid confusion about whether this is an open source Spark contribution or a proprietary third-party plugin.

From the Spark project’s perspective, I also think we should be careful not to blur the line between third-party proprietary extensions and the project itself. Particularly for a feature like OMEMO, the community should not recommend, bundle, or integrate closed-source implementations. Without access to the implementation, there is simply no way for the community to review the code, verify compliance with the relevant XEPs, assess the security properties, or determine whether the licensing is compatible with Spark’s own licensing.

Security features deserve a particularly high standard of transparency. Users should be able to understand what they are trusting when they install software that claims to provide end-to-end encryption.

Finally, if AVHIRAL’s intention is to provide commercial products or services around Ignite Realtime technologies rather than contribute this implementation to Spark, we’d be happy to have the company listed on the Ignite Realtime Professional Service Providers page. That’s exactly the place where organizations offering commercial expertise around our projects can gain visibility, while maintaining a clear distinction between community-maintained open source software and independently developed products.

1 Like

Thank you for your clarification and for your openness.

Our objective is indeed to contribute to the evolution of Spark and to help bring OMEMO support to the project. As indicated previously, the source code is publicly available and distributed through our GitHub repository.

We understand the importance of clearly distinguishing between a third-party product and an official Spark contribution, particularly for a security-related feature. We are therefore fully prepared to improve the repository structure, documentation, licensing information, and presentation in order to remove any ambiguity and make the implementation easier for the community to review.

We would also be very pleased for AVHIRAL to gain greater visibility within the Ignite Realtime ecosystem. Being listed on the Professional Service Providers page would be greatly appreciated, as it would help us introduce our company, our expertise, and the work we are doing around Spark and Ignite Realtime technologies.

Any guidance or assistance you can provide regarding the contribution process, the repository requirements, the technical review, or the professional service provider listing would be very welcome.

Our intention is to work constructively with the community and, where possible, contribute to making Spark more secure and modern.

1 Like