phone

    • chevron_right

      Ignite Realtime Blog: New Openfire plugin: Push Server!

      news.movim.eu / PlanetJabber • 16 September, 2022 • 1 minute

    The Ignite Realtime Community is pleased to announce the 1.0.0 release of the Push Server plugin for Openfire. This plugin is developed by the company Busoft Teknoloji A.Ş. It is inspired by Conversations Push Proxy and developed for Openfire.

    Your instance of Openfire should automatically display the availability of the new plugin in the next few hours. Alternatively, you can download the the plugin directly from the Push Server plugin archive page .

    Stop by our support groupchat to get in touch, or leave a message on our community site .

    For other release announcements and news follow us on Twitter

    What is this plugin for

    Due to the restrictions in push services (FCM or APNS), only the developer can create push notifications for their apps. For this reason a user’s server wouldn’t be able to wake up a user’s device directly but has to proxy that wake up signal through the infrastructure of the app developer.

    Push Server Plugin is an XEP-0357: Push Notifications app server that relays push messages between the user’s server and FCM (Firebase Cloud Messaging) or APNS (Apple Push Notification Service).

    Here is a quick description of how this relationship is set up.

    XMPP Client sends to the app server

    - Device Token
    - Device Id
    

    App Server generates

    - Node Id
    - Secret
    

    App Server stores

    - Device Token
    - Device Id
    - Node
    - Secret
    

    App Server returns to XMPP Client

    - Node Id
    

    XMPP Client sends to the user's server

    - Node ID
    - The jid of the app server (push.example.com)
    

    The user’s server sends to the app server

    (Achived by Openfire Push Notification plugin)

    When a push is required the user’s server will send the node id to the app server. The user’s server can also add additonal information like number of messages pending, the sender jid of the last message and even the body of the last message.

    An example of that communication can be found in XEP-0357 Section 7 .

    9 posts - 3 participants

    Read full topic

    • chevron_right

      Maxime Buquet: Versioning

      news.movim.eu / PlanetJabber • 12 September, 2022 • 2 minutes

    I finally took time to setup a forge and some old drafts turned up. I am publishing one of them today as is even though it’s 4 years old (2018-08-07T13:27:43+01:00). I’m not as grumpy as I was at the time but I still think this applies.

    Today I am grumpy at people’s expectation of a free software project, about versioning and releases. I am mostly concerned about applications rather than libraries in this article but I am sure some of this would apply to libraries as well.

    Today we were discussing about versioning and releases in the poezio chatroom.

    Poezio is a console application, a small project maintained by a handful of contributors to which I am grateful. I also have a few contributions myself. The application is far from perfect but what software is anyway.

    The last release – as of writing – for the project is 0.11 , published on Jan 31, 2017. A bit over 1.5 years ago. Yes, the project is still being actively maintained, but no release is being made for the moment.

    No , not every project releases with the same regularity. No , not every project has the same understanding of what a release is. Most projects don’t have the same constraints.

    For some projects releases are sacred and I am happy for them. Maintained for X months or even years to which will only be applied security fixes or critical bug fixes (crashes and the like).

    For others, releases are only checkpoints. A way of saying that features are being added, bugs are being fixed, and have people talk about it.

    There is no global definition of what a release is supposed to be. It is up to project maintainers to decide what they want to see in it. They could very well make a release every other commit and be happy with it if they wanted to be silly. They would still be semver compliant – one of the various versioning scheme defined out there.

    Nothing also mandates they have to backport bug fixes to the current or previous releases, and some projects actually cannot afford such a luxury. All of this takes time and that is a really expensive resource in a project.

    Update from the present:

    I think the issue I tried to convey in this article isn’t that we don’t have time, or that there’s no definition of a release, it’s that I’m tired of being imposed a vision of the world I don’t agree with. What’s more, people having these expectations often don’t even take part in the process of making the project or the in community around it, at any level.

    • wifi_tethering open_in_new

      This post is public

      bouah.net /2022/09/versioning/

    • chevron_right

      Arnaud Joset: Updates: chatty server and HTTPAuthentificationOverXMPP

      news.movim.eu / PlanetJabber • 11 September, 2022 • 1 minute

    It's been a long time since I updated this blog. It will be a short update post about two projects.

    chatty_server

    The first is chatty_server, a small XMPP bot I use to interact with my server. It allows me to get information about the CPU load, traffic, weather etc. It also has a small feature to get reminder messages. There was a bug that allowed anyone to spam reminders. Anybody can add the bot to their rooster and could create random reminders that I would get. I got none, so the bot must remain quite unheard-of.

    HTTPAuthentificationOverXMPP

    The second project is HTTPAuthentificationOverXMPP, a component that I use to allow 2 Factor authentication with XMPP. The original project had not been updated for a long time and I wanted to try to modify it to rely on another XMPP go library. I have never coded in Go and it seemed like a nice introduction. I relied on go-xmpp where I added the support for XEP 0070 . It was really interesting. The new component is running for several months and I am quite happy with it even if I don't have any serious project relying on it.

    The https://demo.agayon.be/ website is still up if you want to test it.
    I hope being able to provide more update about my projects in the future :-).

    Links

    • wifi_tethering open_in_new

      This post is public

      blog.agayon.be /xmpp_auth_update.html

    • chevron_right

      Monal IM: Monal IM – project moved

      news.movim.eu / PlanetJabber • 10 September, 2022 • 1 minute

    We recently started to migrate the App from Anu Pokharel ‘s Apple account to Thilo Molitor ‘s Apple account.

    As part of this transition we also deployed some new push servers to not let an old retired developer pay for the infrastructure needed for Monal.

    Coming along with this transition from the old developer team to the new one is our new clean website at https://monal-im.org/ . From now on, this blog will not be used for Monal anymore.

    Many thanks to all users, contributors and followers so far.

    Special thanks goes to Anu. Without him and his passion, Monal would not have been possible. He developed and maintained Monal for more than 10 years, always ensuring compatibility with the latest iOS releases.

    When I (Thilo) gradually took over development, I was able to build upon an app with a decent codebase rather than writing my own app from scratch. That made it possible to improve Monal further while already being used by thousands of people. I can not stress enough how thankful I was and still am for all the work Anu put into the development of Monal.
    Thank you, Anu, for your wonderful work towards a modern XMPP client for iOS and macOS!


    Thilo, Friedrich, Anu

    • wifi_tethering open_in_new

      This post is public

      monal.im /blog/monal-im-project-moved/

    • chevron_right

      Dino: Stateless File Sharing: Async, Metadata with Thumbnails and some UI

      news.movim.eu / PlanetJabber • 9 September, 2022 • 3 minutes

    Async

    Asynchronous programming is a neat tool, until you work with a foreign project in a foreign language using it. As a messenger, Dino uses lots of asynchronous code, not always though. Usually my progress wasn’t interfered by such instances, but sometimes I had to work around it.

    Async in Vala

    No surprises here. Functions are annotated with async , and yield expressions that are asynchronous themselves. And you can’t easily call async methods directly in non- async functions.

    Creating problems

    I had a async function I wanted to call in a synchronous context. For quick prototyping, I wanted to call that function and get the result directly by blocking. However, the furthest I got there was a variable in a function that is only initialized if you access it late enough (wouldn’t recommend). At that point I restructured the code so that the async call would actually be in an async context with a simple yield .

    Here a proper introduction to Vala async .

    MetadataProvider

    With the introduction of the metadata element, more metadata can be extracted from files and attached to file transfers. You wouldn’t have guessed, but there are actually a rather big variety of file types. So not only do different files use different metadata fields, but they can also use the fields in different ways.

    To accommodate that relation, the FileManager module now keeps a list of FileMetadataProviders, which will be extended over time. When a file is sent, each provider is asked if it is compatible with the file. If yes, it is called. The first provider is a generic one which is called for every file and fills in name, last-edit-date, size, mime-type and hashes.

    Thumbnail creation

    A special new field is a list of thumbnails. They are intended for small previews of whichever file it is attached to, be it a image, video or pdf. So far, I have implemented thumbnails for images, which introduced two design decisions.

    Size : Which dimensions should the preview have? When it is displayed, it should be stretched to the format of the original image, so the aspect ratio should sort of match. My mentor, larma , suggested that we create very small thumbnails for now, about 8 or 9 pixels. Which dimensions would that allow? 1x8, 2x4, 3x3, 4x2, 8x1. Well, that sounds pretty diverse, no? Those are the dimensions that we use for now, and I select the dimension with the closest aspect ratio.

    Scaling : Now that we have the size, how do we scale the image? Luckily, Gtk (which Vala is closely integrated with), has scaling methods for images. So far, I used bilinear scaling, which is usually the suggested method according to the docs. However, scaling to such a small size results in a lot of gray. While you could probably come up with a fancy custom-made algorithm, I’ll stick with the Gtk built-in methods. Maybe nearest-neighbor could be a better choice, because it would show a ’true’ color from the original image.

    UI

    I tried to hold off on UI work until the last weeks of the projects. While this could’ve easily been due to procrastination (I don’t enjoy UI coding a lot), I actually have a good excuse here. The Dino codebase is being migrated to Gtk4 from Gtk3 this year. Due to this, a lot of UI code is being rewritten, and it would’ve been wasted work to implement new UI elements in the old codebase. The new UI element I introduced is the FilePreviewWidget , which holds a thumbnail of files which are so large that they aren’t immediately downloaded (currently >5 MB). Luckily, the user interaction and graphical components are really close to the FileImageWidget and FileDefaultWidget , so the implementation wasn’t that difficult.

    Progress

    We are nearly finished. The one thing left is source attaching , which the next (and last) progress post will cover. Like always, you can track my progress on the stateless-file-sharing branch. I also created a pre-gtk4-rebase branch stateless-file-sharing-pre-gtk4 .

    • wifi_tethering open_in_new

      This post is public

      dino.im /blog/2022/09/stateless-file-sharing-async-metadata-with-thumbnails-and-some-ui/

    • chevron_right

      Kaidan: Encrypted Audio and Video Calls

      news.movim.eu / PlanetJabber • 3 September, 2022 • 1 minute

    OMEMO logo

    Kaidan will receive a grant by NLnet for adding encrypted audio and video calls.

    The calls will be end-to-end encrypted and authenticated via OMEMO . Furthermore, Kaidan will support small group calls. We strive for interoperability between Kaidan and other XMPP apps supporting calls. In order to achieve that, we will implement a large number of XEPs (XMPP Extension Protocols). They make it possible to have a modern call experience.

    Calls have become more widespread over the past few years in free XMPP chat apps. Especially, grants by NLnet made that possible. The development speed and interoperability between different apps have increased. Such an intense development often results in improved specifications. But sometimes the development overtakes the standardization. In that case, the standardization needs to catch up what has already been implemented.

    We have to handle that circumstance with group calls and invitations to calls at the moment. There are some adjustments that are not yet official. To make calls from Kaidan to other apps already supporting them, we have to base our work on those changes. If those unofficial adjustments are being modified later to become official, we will need to modify Kaidan as well. But we see the evolution of calls in XMPP as a huge progress and are ready for adaption!

    Kaidan’s goal is to establish free and secure communication while being easy to use , thus lowering the entry barrier to XMPP for average users coming from other networks. NLnet and a couple of other organizations support us via the NGI Zero PET fund to achieve that. The money is provided by the European Commission. That is an example of how software can be developed according to the Public Money, Public Code initiative .

    There are many other interesting projects currently funded by NLnet . We are glad that Kaidan is one of them!

    • wifi_tethering open_in_new

      This post is public

      kaidan.im /2022/09/03/audio-video-calls/

    • chevron_right

      Paul Schaub: Creating a Web-of-Trust Implementation: Accessing Certificate Stores

      news.movim.eu / PlanetJabber • 1 September, 2022 • 6 minutes

    Currently, I am working on a Web-of-Trust implementation for the OpenPGP library PGPainless. This work is being funded by the awesome NLnet foundation through NGI Assure . Check them out! NGI Assure is made possible with financial support from the European Commission’s Next Generation Internet programme .

    NLnet
    NGI Assure

    In this post, I will outline some progress I made towards a full WoT implementation. The current milestone entails integrating certificate stores more closely with the core API.

    On most systems, OpenPGP certificates (public keys) are typically stored and managed by GnuPGs internal key store. The downside of this approach is, that applications that want to make use of OpenPGP either need to depend on GnuPG, or are required to manage their very own exclusive certificate store. The latter approach, which e.g. Thunderbird is taking, leads to a situation where there are multiple certificate stores with different contents. Your GnuPG certificate store might contain Bobs certificate, while the Thunderbird store does not. This is confusing for users, as they now have to manage two places with OpenPGP certificates.

    There is a proposal for a Shared PGP Certificate Directory nicknamed “pgp.cert.d” which aims to solve this issue by specifying a shared, maildir-like directory for OpenPGP certificates. This directory serves as a single source for all OpenPGP certificates a user might have to deal with. Being well-defined through the standards draft means different applications can access the certificate store without being locked into a single OpenPGP backend.

    Since the Web-of-Trust also requires a certificate store of some kind to work on, I thought that pgp.cert.d might be the ideal candidate to implement. During the past months I reworked my existing implementation to allow for different storage backends and defined an abstraction layer for generalized certificate stores (not only pgp.cert.d). This abstraction layer was integrated with PGPainless to allow encryption and verification operations to request certificates from a store. Let me introduce the different components in more detail:

    The library pgp-cert-d-java contains an implementation of the pgp.cert.d specification. It provides an API for applications to store and fetch certificates to and from the pgp.cert.d directory. The task of parsing the certificate material was delegated to the consumer application, so the library is independent from OpenPGP backends.

    The library pgp-certificate-store defines an abstraction layer above pgp-cert-d-java . It contains interfaces for a general OpenPGP certificate store. Implementations of this interface could for example access GnuPGs certificate store, since the interface does not make assumptions about how the certificates are stored. Inside pgp-cert-d-java , there is an adapter class that adapts the PGPCertificateDirectory class to the PGPCertificateStore interface.

    The pgpainless-cert-d module provides certificate parsing functionality using pgpainless-core . It further provides a factory class to instantiate PGPainless-backed instances of the PGPCertificateDirectory interface (both file-based, as well as in-memory directories).

    Lastly, the pgpainless-cert-d-cli application is a command line tool to demonstrate the pgp.cert.d functionality. It can be used to manage the certificate directory by inserting and fetching certificates:

    $ pgpainless-cert-d-cli help
    Store and manage public OpenPGP certificates
    Usage: certificate-store [-s=DIRECTORY] [COMMAND]
    
    Options:
      -s, --store=DIRECTORY   Overwrite the default certificate directory path
    
    Commands:
      help    Display the help text for a subcommand
      export  Export all certificates in the store to Standard Output
      insert  Insert or update a certificate
      import  Import certificates into the store from Standard Input
      get     Retrieve certificates from the store
      setup   Setup a new certificate directory
      list    List all certificates in the directory
      find    Lookup primary certificate fingerprints by subkey ids or fingerprints
    Powered by picocli
    

    Now let’s see how the certificate store can integrate with PGPainless:

    Firstly, let’s set up a pgp.cert.d using pgpainless-cert-d-cli:

    $ pgpainless-cert-d-cli setup
    facf859c9dc1106c4a30f56b1c38b70b755017cf

    This command initializes the certificate directory in .local/share/pgp.cert.d/ and creates a trust-root key with the displayed fingerprint. This trust-root currently is not of use, but eventually we will use it as the root of trust in the Web-of-Trust.

    Just for fun, let’s import our OpenPGP certificates from GnuPG into the pgp.cert.d:

    $ gpg --export --armor | pgpainless-cert-d-cli import

    The first part of the command exports all public keys from GnuPG, while the second part imports them into the pgp.cert.d directory.

    We can now access those certificates like this:

    $ pgpainless-cert-d-cli get -a 7F9116FEA90A5983936C7CFAA027DB2F3E1E118A
    -----BEGIN PGP PUBLIC KEY BLOCK-----
    Version: PGPainless
    Comment: 7F91 16FE A90A 5983 936C  7CFA A027 DB2F 3E1E 118A
    Comment: Paul Schaub <vanitasvitae@fsfe.org>
    Comment: 2 further identities
    
    mQINBFfz1ucBEADXSvUjnOWSzgW5hXki1xUpGv7vacT8XqqGbO9Z32P3eFxa4E9J
    vveJmx+voxRWpleZ/L6XCYYmCKnagjF0fMxFD1Zxicp5tzbruC1cm/Els0IJVjFV
    RLke3SegTHxHncA8+BYn2k/VnTKwDXzP0ZLyc7mUbDl8CCtWGGUkXpaa7WyZIA/q
    [...]
    -----END PGP PUBLIC KEY BLOCK-----

    Would this certificate change over time, e.g. because someone signs it and sends me an updated copy, I could merge the new signatures into the store by simply inserting the updated certificate again:

    pgpainless-cert-d-cli insert < update.asc

    Now, I said earlier that the benefit of the pgp.cert.d draft was that applications could access the certificate store without the need to rely on a certain backend. Let me demonstrate this by showing how to access my certificate within a Java application without the need to use pgpainless-cert-d-cli .

    First, let’s write a small piece of code which encrypts a message to my certificate:

    // Setup the store
    SubkeyLookupFactory lookupFactory = new DatabaseSubkeyLookupFactory();
    PGPCertificateDirectory pgpCertD = PGPainlessCertD.fileBased(lookupFactory);
    PGPCertificateStoreAdapter store = new PGPCertificateStoreAdapter(pgpCertD);
    
    OpenPgpFingerprint myCert = OpenPgpFingerprint.parse("7F9116FEA90A5983936C7CFAA027DB2F3E1E118A");
    
    ByteArrayInputStream plaintext = new ByteArrayInputStream("Hello, World! This message is encrypted using a cert from a store!".getBytes());
    ByteArrayOutputStream ciphertextOut = new ByteArrayOutputStream();
    
    // Encrypt
    EncryptionStream encryptionStream = PGPainless.encryptAndOrSign()
      .onOutputStream(ciphertextOut)
      .withOptions(ProducerOptions.encrypt(
        EncryptionOptions.encryptCommunications()
          .addRecipient(adapter, myCert)));
    Streams.pipeAll(plaintext, encryptionStream);
    encryptionStream.close();
    
    System.out.println(ciphertextOut.toString())

    In this example, we first set up access to the shared certificate directory. For that we need a method to look up certificates by subkey-ids. In this case this is done through an SQLite database. Next, we instantiate a PGPCertificateDirectory object, which we then wrap in a PGPCertificateStoreAdapter to make it usable within PGPainless.

    Next, we only need to know our certificates fingerprint in order to instruct PGPainless to encrypt a message to it. Lastly, we print out the encrypted message.

    In the future, once the Web-of-Trust is implemented, it should be possible to pass in the recipients email address instead of the fingerprint. The WoT would then find trustworthy keys with that email address and select those for encryption. Right now though, the user still has to identify trustworthy keys of recipients themselves still.

    Similarly, we can use a certificate store when verifying a signed message:

    ByteArrayInputStream ciphertextIn = ...; // signed message
    ByteArrayOutputStream plaintextOut = new ByteArrayOutputStream();
    
    // Verify
    DecryptionStream verificationStream = PGPainless.decryptAndOrVerify()
      .onInputStream(ciphertextIn)
      .withOptions(new ConsumerOptions()
        .addVerificationCerts(adapter));
    Streams.pipeAll(verificationStream, plaintextOut);
    verificationStream.close();
    
    OpenPgpMetadata result = decryptionStream.getResult();
    assertTrue(result.isVerified()); // signature is correct and valid
    assertTrue(result.containsVerifiedSignatureFrom(myCert));

    Here, PGPainless will process the signed message, identify the key that was used for signing and fetch its certificate from the certificate store.

    Note, that if you implement verification like that, it is up to you to verify the trustworthiness of the certificate yourself.

    In the future, this task will be done by a WoT library in the PGPainless ecosystem automatically though 🙂

    The current state of the certificate store integration into PGPainless can be found on the storeIntegration branch.

    • wifi_tethering open_in_new

      This post is public

      blog.jabberhead.tk /2022/09/01/creating-a-web-of-trust-implementation-accessing-certificate-stores/

    • chevron_right

      Ignite Realtime Blog: Openfire ThreadDump plugin 1.1.0 released

      news.movim.eu / PlanetJabber • 31 August, 2022

    Earlier today, we have released version 1.1.0 of the Openfire Thread Dump plugin. This plugin uses various evaluators to trigger the creation of a Java thread dump. These thread dumps provide valuable information that is typically used when analyzing issues within Openfire’s implementation.

    In the new version of the plugin, two new evaluators have been added: one that looks at the usage pattern of Openfire’s TaskEngine, and another one that uses statistics from the database connection pool.

    The updated plugin should become available for download in your Openfire admin console in the course of the next few hours. Alternatively, you can download the plugin directly, from the plugin’s archive page .

    For other release announcements and news follow us on Twitter

    1 post - 1 participant

    Read full topic

    • chevron_right

      Kaidan: Kaidan's End-to-End Encryption Trust Management

      news.movim.eu / PlanetJabber • 31 August, 2022 • 2 minutes

    We worked several months on Kaidan’s upcoming end-to-end encryption and trust management. Once Kaidan 0.9 is released, it will provide the latest OMEMO Encryption . But it will also make trust decisions in the background for you if it’s possible. Some trust decisions have to be made manually but there are many others Kaidan automates without decreasing your security. That is done by automatically sharing trust decisions via already secured channels.

    The feature Kaidan uses is called Automatic Trust Management (ATM) . Your device receives the encryption data to secure the conversation between you and your contact via the internet. That encryption data can be the data of an attacker. While you think that you communicate with your contact securely, the attacker can read, modify or drop everything you exchange.

    You have to make sure that the encryption data you received are really those from your contact to detect and stop an attack. That is done by comparing the exchanged encryption data via a second secure channel. Kaidan provides QR codes for that. QR codes are especially helpful when you want a secure conversation with a contact you can meet in person. For that, you simply scan your contact’s QR code and vice versa.

    First QR code scan

    Second QR code scan

    But what if your contact used a smartphone during the first QR code scan and now wants to chat with you via a notebook too? Usually, your contact would have to scan the notebook’s QR code with the smartphone and vice versa. Furthermore, you would have to scan the notebook’s QR code and vice versa. If you or your contact gets another device or even replaces an old one, QR codes have to be scanned again. That leads to multiple mutual scans, one for each pair of devices.

    In the following example graph, there are four devices. B1, B2 and B3 could be your contact’s devices and A1 yours. The six gray edges are the mutual QR code scans that are needed to stop all possible attacks.

    Needed trust decisions

    With ATM, many QR code scans between you and your contact become unnecessary. The first meeting is used for the initial scan. The encryption data of all new devices is checked via the secure channel established by it. If your contact wants to chat via the notebook, your contact simply scans the notebook via the smartphone and vice versa. But all other scans are not needed anymore. The trust decisions are communicated between the devices that already have a secure channel.

    In the example graph, ATM could work as follows:

    1. A1 scans B1’s QR code and vice versa.
    2. A1 scans A2’s QR code and vice versa.
    3. A2 scans A3’s QR code and vice versa.
    4. The remaining three edges are created automatically by ATM via the existing secure channels.

    If you want to try out that new feature, stay tuned! Our next release will come soon.

    • wifi_tethering open_in_new

      This post is public

      kaidan.im /2022/08/31/e2ee-trust-management/