Attention iOS beta testers. I am upgrading the iOS push servers tonight.  There might be some downtime as the DNS changes propagate. You will also have the close and reopen Monal to register with the new server.  After restarting, make sure that the push switches are  all on in the Notifications under Settings.

There is a long running joke about open source software that it is almost always a paragon of poor UI/UX.  If you have ever struggled with software on linux you know that sometimes it can be impenetrable.  I don’t blame developers, UI/UX is hard and when you are the same person developing and testing it, it is easy to forget that works for me may not work for everyone else.

This is sort of how we need to think about accessibility. It is really hard to understand how someone else will use it if you are used to always using your app one way.    With that in mind I recommend other developers use the Accessibility Inspector and Voice over to get an idea for how accessible their software is.

I have made several improvements to the next Mac release to address issues with accessibility.  The elements of the UI should have descriptions and help text where applicable. You can now navigate through the conversations list and quickly hear your messages, who sent them and where they came from.  I will keep improving  in future update (and check iOS as well ) let me know how I can make this better.

I have brought the new MAM and controls code to iOS and added the following screens to the accounts screen.

I have finally had the time to take a look at OMEMO. I know that end to end encrypted chat has been something people have requested for almost a decade now.  There finally appears to be a workable solution it a permissive license that can be published in the App Store.

As usual, the Mac client is my testing ground for new logic and I will probably focus the next release after this one on E2E encryption.  I know that OTR was something former Adium users missed, I hope that a native Mac client with a user friendly OMEMO interface fills the gap there.  I’ve been looking at Gajim and Chatsecure and will probably fish out a Android tablet (actually an HP touchpad)  from somewhere to test with Conversations too.

There is another new beta for the Mac client. I’ve made a few UI fixes and adjustments to MAM. Generally, I think the MAM code is working well enough that I will push this client out to production with some more UI fixes.  You will probably see me working on Mac UI issues on GitHub for a little bit.

Regarding iOS. I am still unhappy with the push server. At the moment it is not properly throttling pushes and I see far more pushes coming for a single message  than there should be. There are also issues with the XMPP spec (XEP) that I am unhappy about. In particular, I feel pushes should only happen for messages and voip calls and nothing else.  It appears to be happening for far more than that.  Due to the way that push is designed for user privacy, I don’t see what content is triggering a push. It is entirely dependent on individual servers.

Today we removed support for XMPP in Fanout Cloud.

Fanout’s XMPP functionality simply didn’t garner the adoption we were hoping for. It was never used at scale, and was mainly relegated to chat bots that needed compatibility with Google Talk. However, as Google phased out XMPP federation, such usefulness dwindled.

...

BouncyCastle

The mystery has been solved! I finally found out, why the OpenPGP keys I generated for my project had a broken format. Turns out, there was a bug in BouncyCastle.
Big thanks to Heiko Stamer, who quickly identified the issue in the bug report I created for pgpdump, as well as Kazu Yamamoto and David Hook, who helped identify and confirm the issue.

The bug was, that BouncyCastle, when exporting a secret key without a password, was appending 20 bytes of the SHA1 hash after the secret key material. That is only supposed to happen, when the key in fact is password protected. In case of unprotected keys, BouncyCastle is supposed to add a two byte checksum instead. BouncyCastles wrong behaviour cause pgpdump to interpret random bytes as packet tags, which resulted in a wrong key id being printed out.

The relevant part of RFC-4880 is found in section 5.5.3:

      -If the string-to-key usage octet is zero or 255, then a two-octet
       checksum of the plaintext of the algorithm-specific portion (sum
       of all octets, mod 65536).  If the string-to-key usage octet was
       254, then a 20-octet SHA-1 hash of the plaintext of the
       algorithm-specific portion.

Shortly after I filed a bug report for BouncyCastle, Vincent Breitmoser, one of the Authors of XEP-0373 and XEP-0374 submitted a fix for the bug. This is a nice little example of how free software projects can work together to improve each other. Big thanks for that

Working OX Test Client!

I spent the last night to create a command line chat client that can “speak” OX. Everything is a little bit rough around the edges, but the core functionality works.
The user has to do actions like publishing and fetching keys by hand, but encrypted, signed messages can be exchanged. Having working code, I can now start to formulate a general API which will enable multiple OpenPGP back-ends. I will spend some more time to polish that client up and eventually publish it in a separate git repository.

EFAIL

I totally forgot to talk about EFAIL in my last blog posts. It was a little shock when I woke up on Monday, the first day of the coding phase, only to read sentences like “Are you okay?” or “Is the GSoC project in danger?”
I’m sure you all have read about the EFAIL attack somewhere in the media, so I’m not going into too much detail here (the EFF already did a great job *cough cough*). The E-Fail website describes the attack as follows:

Is EFAIL applicable to XMPP?
Probably not to the XEPs I’m implementing. In case of E-Mail, it is relatively easy to prepend the image tag to the message. XEP-0373 however specifies, that the transported extension elements (eg. the body of the message) is wrapped inside of an additional extension element, which is then encrypted. Additionally this element (eg. <signcrypt/>) carries a random length, random content padding element, so it is very hard to nearly impossible for an attacker to guess, where the actual body starts, and in turn where they’d have to insert an “extraction channel” (eg. image tag) to the message.

In legacy OpenPGP for XMPP (XEP-0027) it is theoretically possible to at least execute the first part of the attack made in EFAIL. An attacker could insert an image tag to make a link out of the message. However, external images are usually shared by using XEP-0066 (Out of Band Data) by adding an x-element with the oob namespace to the message, which contains the URL to the image. Note, that this element is added outside the body though, so we should be fine, as so the attack would only work if the user tried to open the linkified message in a browser

Another option for the attacker would be to attack XHTML-IM (XEP-0071) messages, but I think those do not support legacy OpenPGP in the first place. Also XHTML-IM has been deprecated recently *phew*.

In the end, I’m by no means a security expert, so please do not quote me on my wild thoughts here
However it is important to learn from that example to not make the same mistakes some Email clients did.

Happy Hacking!

As many people know the EU’s GDPR regulations come into effect on May 25th. While Monal is privacy focused, it is also free, open source and run by a single person — me.  I simply do not have the resources or the time to jump through the regulatory hoops required by the EU.  While I do not live in the EU, I frequent Europe and do not want to get into legal trouble on vacation.  As GDPR approaches, I get the impression that it is an end of an era for the internet. The days of someone making something, putting it on the internet and offering it to the world seem to be over.  EU users can always download the source on GitHub and compile the iOS app but they will be blocked from using push when I deploy it.

The problems below are likely not unique to me and there are many other issues. Other open source projects may want to consider their fate under GDPR as well.

Data Protection Officer

I do not have the resources to hire a Data Protection Officer (DPO) or EU Representative as required by GDPR.  I do not have designated EU contacts.

Crashes

Tracking crashes with Crashlytics introduces new issues because it is posted to Fabric from a user’s device,  IP addresses are in the logs this is  personally identifiable information  (PII).  Crashlytics  is GDPR compliant but the burden is on me to show  regulators that I am compliant points back to the need for DPO.

Push

Even though no message traffic passes through Monal’s sever, registering for a push does make an HTTP call which logs a user’s IP and this  requires GDPR compliance.  APNS push tokens are associated with devices which can be traced back to a user if combined with info on the originating XMPP server. Obviously, this is needed for a notification to be delivered to the right person. However,the fact that it can be combined to identify a person makes it PII. I believe in privacy but I do not have the resources to meet the letter of the law for compliance especially with respect to retention and processing these tokens.

XMPP Federation in General

Honestly, I do not know if XMPP federation is legal anymore in the EU with GDPR.  EU user data is sent out of Europe constantly.  GDPR is written such that a user cannot agree to a user agreement that gives up GDPR requirements it’s not a matter of saying you agree to X by using this service. GDPR compliance is something the XSF is talking about right now.

I noticed that my blog posting frequency is substantially higher than last year. For that reason I’ll try to keep this post shorter.

Yesterday I implemented my first prototype code to encrypt and decrypt XEP-0374 messages! It can process incoming PubkeyElements (the published OpenPGP keys of other users) and create SigncryptElements which contain a signed and encrypted payload. On the receiving side it can also decrypt those messages and verify the signature.

I’m still puzzled about why I’m unable to dump the keys I generate using pgpdump. David Hook from Bouncycastle used my code to generate a key and it worked flawlessly on his machine, so I’m stumped for an answer…

I created a bug report about the issue on the pgpdump repository. I hope that we will get to the cause of the issue soon.

Changes to the schedule

In my original proposal I sketched out a timeline which is now (that I already making huge steps) a little bit underwhelming. The plan was initially to work on Smacks PubSub API within the first two weeks.
Florian suggested, that instead I should create a working prototype of my implementation as soon as possible, so I’m going to modify my schedule to meet the new criteria:

My new plan is, to have a fully working prototype implementation at the time of the first evaluation (june 15th).
That prototype (implemented within a small command line test client) will be capable of the following things:

• Storing keys in a rudimental form on disk
• automatically creating keys if needed
• publishing public keys via PubSub
• fetching contacts keys when needed
• encrypting and signing messages
• decrypting and verifying and displaying incoming messages

The final goal is still to create a sane, modular implementation. I’m just slightly modifying the path that will take me there

We are pleased to announce a new minor release from our stable branch.

This is the latest release to our stable branch. It is recommented that all 0.10.0 users upgrade, and users of our nightly packages upgrade to build 477 or later.

A summary of changes in this release:

Security

• SQL: Ensure user archives are purged when a user account is deleted (fixes #1009)

Fixes and improvements

• Core: More robust signal handling (fixes #1047, #1029)
• MUC: Ensure that elements which match our from are stripped (fixes #1055)
• MUC: More robust handling of storage failures (fixes #1091, #1091)
• mod_mam: Ensure a user's archiving preferences apply even when they are offline (fixes #1024)
• Compatibility improvements with LuaSec 0.7, improving curve support
• mod_stanza_debug: New module that logs full stanzas sent and received for debugging purposes
• mod_mam: Implement option to enable MAM implicitly when client support is detected (#867)
• mod_mam: Add an option for whether to include 'total' counts by default in queries (for performance)
• MUC: send muc#stanza_id feature as per XEP-0045 v1.31 (fixes #1097)

Minor changes

• SQL: Suppress error log if a transaction failed but was retried ok
• core.stanza_router: Verify that xmlns exists for firing stanza/iq/xmlns/name events (fixes #1022) (thanks SamWhited)
• mod_carbons: Synthesize a 'to' attribute for carbons of stanzas to "self" (fixes #956)
• Core: Re-enable timestamps by default when logging to files (fixes #1004)
• HTTP: Report HTML Content-Type on error pages (fixes #1030)
• mod_c2s: Set a default value for c2s_timeout (fixes #1036)
• prosodyctl: Fix traceback with lfs < 1.6.2 and show warning
• Fix incorrect '::' compression of a single 0-group which broke some IPv6 address matching
• mod_dialback: Copy function from mod_s2s instead of depending on it, which made it harder to disable s2s (fixes #1050)
• mod_storage_sql: Add an index to SQL archive stores to improve performance of some queries
• MUC: Don't attempt to reply to errors with more errors (fixes #1122)
• Module API: Fix parameter order to http client callbacks
• mod_blocklist: Allow mod_presence to handle subscription stanzas before bouncing outgoing presence (fixes #575)
• mod_http_files: Fix directory listing cache entries not expiring (fixes #1130)

Download

As usual, download instructions for many platforms can be found on our download page

If you have any questions, comments or other issues with this release, let us know!

The Coding Phase has begun! Unfortunately my first (official) day of coding was a bad start, as I barely added any new code. Instead I got stuck on a very annoying bug. On the bright side, I’m now writing a lengthy blog post for you all, whining about my issue in all depth. But first lets continue where we left off in this post.

In the last part of my OpenPGP TL;DR, I took a look at different packet types of which an OpenPGP message may consist of. In this post, I’ll examine the structure of OpenPGP keys.

Just like an OpenPGP message, a key pair is made up from a variety of sub packets. I will now list some of them.

Key Material

First of all, there are four different types of key material:

• Public Key
• Public Sub Key
• Secret Key
• Secret Sub Key

It should be clear, what Public and Secret keys are.
OpenPGP defines a way to create key hierarchies, where sub keys belong to master keys. A typical use-case for this is when a user has multiple devices, but doesn’t want to risk losing their main key pair in case a device gets stolen. In such a case, they would create one super key (pair), which has a bunch of sub keys, one for every device of the user. The super key, which represents the identity of the user is used to sign all sub keys. It then gets locked away and only the sub keys are used. The advantage of this model is, that all sub keys clearly belong to the user, as all of them are signed by the master key. If one device gets stolen, the user can simply revoke that single key, without losing all their reputation, as the super key is still valid.

I still have to determine, whether my implementation should support sub keys, and if so, how that would work.

Signature

This model brings us directly to another, very important type of sub packet – the Signature Packet. A signature can be seen as a statement. How that statement is to be interpreted is defined by the type of the signature.
There are currently 3 different types of signatures, all with different meanings:

• Certification Signature
  Signatures are often used as attestation. If I sign your PGP key for example, I attest other users, that I have to some degree verified, that you are the person you claim to be and that the key belongs to you.
• Sub Key Binding Signature
  If a key has such a signature, the key is a sub key of the key that made the signature. In other words: The signature is a statement, that the key that made the signature owns the signed key.
• Direct-Key Signature
  This type of signature is mostly used to bind additional information in form of Signature Sub Packets to a key. We will see later, what type of information that may be.

Issuing signatures shall not be taken too lightly. In the end, a signature is a statement, which will be interpreted. Creating trust signatures on keys without verifying their authenticity for example may seriously harm ecosystems like the Web of Trust.

Signature Sub Packets

What’s the purpose of Signature Sub Packets?
Signature Sub Packets are used to bind information to a key. Examples are:

• Creation and expiration dates.
  It might be useful to know, how long a key should be in use. For that purpose the owner of the key can set an expiration date, after which the key should no longer be used.
  It is also possible to let signatures expire.
• Preferred Algorithms
  The user can state, which algorithms (hashing, compressing and symmetric encryption) they want their interlocutors to use when creating a message.
• Revocation status
  It might be necessary to revoke a key that has been compromised. That can be done by placing a signature on it, stating that the key should no longer be used.
• Trust Signature
  If a signature contains a trust signature packet, the signature is to be interpreted as an attestation of trust in that key.
• Primary User ID
  A user can specify the main user id of a key.

User ID

User IDs are stating, to which identity of a user a key belongs. That might be a real or a companies name, an email address or in our case a Jabber ID.
Sub keys can have different user ids, that way a user can differentiate between different roles.

Trust

Trust can not only be expressed by a Trust Signature (mentioned before), but also by a Trust packet. The difference is, that the signature is cryptographically backed, while a trust packet is merely an indicator.
Trust packets are mostly used by a user to keep track of which keys of contacts they trust themselves.

There is currently no XEP specifying how trust decisions of a user are synchronized across multiple devices in the context of XMPP. #FutureWork?

 Bouncycastle and (the not so painless) PGPainless

As I mentioned in my very last post, I was able to generate an OpenPGP key pair using GnuPG (using the “–allow-freeform-uids” flag to allow the uid format used by xmpp). The next step was trying to generate keys on my own using Bouncycastle. Bouncy-gpg (the library I forked into PGPainless) does not offer convenient methods for creating keys, so thats one feature I’ll add to PGPainless and hopefully upstream to Bouncy-gpg. I already created some basic builder structure for creating OpenPGP key pairs using RSA. In order to generate a key pair, the user would do this:

PGPSecretKeyRing secRing = BouncyGPG.createKeyPair()
        .withRSAKeys()
        .ofSize(PublicKeySize.RSA._2048)
        .forIdentity("xmpp:average@best.net")
        .withPassphrase("monkey123")
        .build()
        .generateSecretKeyRing();

Pretty easy, right? Behind the scenes, PGPainless is generating the key pair using the following code:

KeyPairGenerator pbkcGenerator = KeyPairGenerator.getInstance(
        BuildPGPKeyGeneratorAPI.this.keyType, PROVIDER);
pbkcGenerator.initialize(BuildPGPKeyGeneratorAPI.this.keySize);

// Underlying public-key-cryptography key pair
KeyPair pbkcKeyPair = pbkcGenerator.generateKeyPair();

// hash calculator
PGPDigestCalculator calculator = new JcaPGPDigestCalculatorProviderBuilder()
        .setProvider(PROVIDER)
        .build()
        .get(HashAlgorithmTags.SHA1);

// Form PGP key pair //TODO: Generalize "PGPPublicKey.RSA_GENERAL" to allow other crypto
PGPKeyPair pgpPair = new JcaPGPKeyPair(PGPPublicKey.RSA_GENERAL, pbkcKeyPair, new Date());

// Signer for creating self-signature
PGPContentSignerBuilder signer = new JcaPGPContentSignerBuilder(
        pgpPair.getPublicKey().getAlgorithm(), HashAlgorithmTags.SHA256);

// Encryptor for encrypting the secret key
PBESecretKeyEncryptor encryptor = passPhrase == null ?
        null : // unencrypted key pair, otherwise AES-256 encrypted
        new JcePBESecretKeyEncryptorBuilder(PGPEncryptedData.AES_256, calculator)
                .setProvider(PROVIDER)
                .build(passPhrase);

// Mimic GnuPGs signature sub packets
PGPSignatureSubpacketGenerator hashedSubPackets = new PGPSignatureSubpacketGenerator();

// Key flags
hashedSubPackets.setKeyFlags(false,
        KeyFlags.CERTIFY_OTHER
                | KeyFlags.SIGN_DATA
                | KeyFlags.ENCRYPT_COMMS
                | KeyFlags.ENCRYPT_STORAGE
                | KeyFlags.AUTHENTICATION);

// Encryption Algorithms
hashedSubPackets.setPreferredSymmetricAlgorithms(false, new int[]{
        PGPSymmetricEncryptionAlgorithms.AES_256.getAlgorithmId(),
        PGPSymmetricEncryptionAlgorithms.AES_192.getAlgorithmId(),
        PGPSymmetricEncryptionAlgorithms.AES_128.getAlgorithmId(),
        PGPSymmetricEncryptionAlgorithms.TRIPLE_DES.getAlgorithmId()
});

// Hash Algorithms
hashedSubPackets.setPreferredHashAlgorithms(false, new int[] {
        PGPHashAlgorithms.SHA_512.getAlgorithmId(),
        PGPHashAlgorithms.SHA_384.getAlgorithmId(),
        PGPHashAlgorithms.SHA_256.getAlgorithmId(),
        PGPHashAlgorithms.SHA_224.getAlgorithmId(),
        PGPHashAlgorithms.SHA1.getAlgorithmId()
});

// Compression Algorithms
hashedSubPackets.setPreferredCompressionAlgorithms(false, new int[] {
        PGPCompressionAlgorithms.ZLIB.getAlgorithmId(),
        PGPCompressionAlgorithms.BZIP2.getAlgorithmId(),
        PGPCompressionAlgorithms.ZIP.getAlgorithmId()
});

// Modification Detection
hashedSubPackets.setFeature(false, Features.FEATURE_MODIFICATION_DETECTION);

// Generator which the user can get the key pair from
PGPKeyRingGenerator ringGenerator = new PGPKeyRingGenerator(
        PGPSignature.POSITIVE_CERTIFICATION, pgpPair,
        BuildPGPKeyGeneratorAPI.this.identity, calculator,
        hashedSubPackets.generate(), null, signer, encryptor);

return ringGenerator;

Using the above code, I’m trying to create a key pair which is constructed equally as a key generated using GnuPG. I do this mainly to make sure that I don’t have any errors in my code. Also GnuPG is an implementation of OpenPGP with a lot of reputation. If I do what they do, chances are that I might do it right ;D

Unfortunately I’m not quite sure, whether I’m successful with this method or not. To explain my uncertainty, let me show you the output of pgpdump, a tool used to analyse OpenPGP keys:

$pgpdump gnupg.sec
Old: Secret Key Packet(tag 5)(920 bytes)
    Ver 4 - new
    Public key creation time - Tue May  8 15:15:42 CEST 2018
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(2048 bits) - ...
    RSA e(17 bits) - ...
    RSA d(2046 bits) - ...
    RSA p(1024 bits) - ...
    RSA q(1024 bits) - ...
    RSA u(1024 bits) - ...
    Checksum - 3b 8c
Old: User ID Packet(tag 13)(23 bytes)
    User ID - xmpp:juliet@capulet.lit
Old: Signature Packet(tag 2)(334 bytes)
    Ver 4 - new
    Sig type - Positive certification of a User ID and Public Key packet(0x13).
    Pub alg - RSA Encrypt or Sign(pub 1)
    Hash alg - SHA256(hash 
    Hashed Sub: issuer fingerprint(sub 33)(21 bytes)
     v4 -    Fingerprint - 1d 01 8c 77 2d f8 c5 ef 86 a1 dc c9 b4 b5 09 cb 59 36 e0 3e
    Hashed Sub: signature creation time(sub 2)(4 bytes)
        Time - Tue May  8 15:15:42 CEST 2018
    Hashed Sub: key flags(sub 27)(1 bytes)
        Flag - This key may be used to certify other keys
        Flag - This key may be used to sign data
        Flag - This key may be used to encrypt communications
        Flag - This key may be used to encrypt storage
        Flag - This key may be used for authentication
    Hashed Sub: preferred symmetric algorithms(sub 11)(4 bytes)
        Sym alg - AES with 256-bit key(sym 9)
        Sym alg - AES with 192-bit key(sym 
        Sym alg - AES with 128-bit key(sym 7)
        Sym alg - Triple-DES(sym 2)
    Hashed Sub: preferred hash algorithms(sub 21)(5 bytes)
        Hash alg - SHA512(hash 10)
        Hash alg - SHA384(hash 9)
        Hash alg - SHA256(hash 
        Hash alg - SHA224(hash 11)
        Hash alg - SHA1(hash 2)
    Hashed Sub: preferred compression algorithms(sub 22)(3 bytes)
        Comp alg - ZLIB <RFC1950>(comp 2)
        Comp alg - BZip2(comp 3)
        Comp alg - ZIP <RFC1951>(comp 1)
    Hashed Sub: features(sub 30)(1 bytes)
        Flag - Modification detection (packets 18 and 19)
    Hashed Sub: key server preferences(sub 23)(1 bytes)
        Flag - No-modify
    Sub: issuer key ID(sub 16)(8 bytes)
        Key ID - 0xB4B509CB5936E03E
    Hash left 2 bytes - 87 ec
    RSA m^d mod n(2048 bits) - ...
        -> PKCS-1

Above you can see the structure of an OpenPGP RSA key generated by GnuPG. You can see its preferred algorithms, the XMPP UID of Juliet and so on. Now lets analyse a key generated using PGPainless.

$pgpdump pgpainless.sec
Old: Secret Key Packet(tag 5)(950 bytes)
    Ver 4 - new
    Public key creation time - Mon May 14 15:56:21 CEST 2018
    Pub alg - RSA Encrypt or Sign(pub 1)
    RSA n(2048 bits) - ...
    RSA e(17 bits) - ...
    RSA d(2046 bits) - ...
    RSA p(1024 bits) - ...
    RSA q(1024 bits) - ...
    RSA u(1023 bits) - ...
    Checksum - 6d 18
New: unknown(tag 48)(173 bytes)
Old: Signature Packet(tag 2)(until eof)
    Ver 213 - unknown

Unfortunately the output indicates an unknown packet tag and it looks like something is broken. I’m not sure what’s going on, but I suspect either an error in my implementation, or a bug in Bouncycastle. I noticed, that the output of pgpdump is drastically changing if I change the first boolean value in any of the hashedSubPackets setter function calls from false to true (that boolean represents, whether the set value is “critical”, meaning whether the receiving implementation should throw an error in case the read property is unknown). If I do set it to true, the output looks more disturbing and broken, since strange unicode symbols start to appear, indicating a bug. Unfortunately my mail to the Bouncycastle mailing list is still unanswered, although I must add that I wrote it only seven hours ago.

It is a real pity, that it is so hard to find working example code that is not outdated If you can point me in the right direction, please let me know!! You can find contact details on my Github page.

My next steps debugging this will be trying whether an exported key can successfully be imported both back into PGPainless, as well as into GnuPG. Apart from that, I will spend more time thinking about an API which allows different OpenPGP backends.

Happy Hacking!

@Flow wrote:

Smack 4.3.0-beta2 has been released. As always the release artifacts are available on Maven Central.

This release includes important fixes and improvements. The full list of resolved issues can be found in our issue tracker. We are aware that Smack 4.2 introduced some big but necessary API changes, hence you may be happy to hear that the changes between Smack 4.2. and 4.3 are much smaller. Users are encouraged to apply Smack 4.3.0-beta2 in the beta versions of their software.

It also marks an important milestone in Smack’s development cycle as the ‘4.3’ branch was created, meaning that there are no major API changes to be expected. We hope to end the beta period within the next weeks with the first release candidate for Smack 4.3. Until then, please use Smack’s community forums for feedback and suggestions.

Posts: 1

Participants: 1

Read full topic

This is a new maintenance release to our old stable 0.9 branch, with many bug fixes, including some important security improvements.

In particular there is an issue where using Prosody 0.9 with LuaSocket 3.0rc1 (which is commonly packaged in distributions) can allow an unauthenticated remote entity to trigger Prosody to exit.

If you are using our nightly packages ('prosody-0.9') from our repository, this issue was already fixed last year in nightly build 285. Simply upgrade the prosody-0.9 package to ensure you have all the latest fixes in this branch.

If you are using the 'prosody' package and it is at version 0.9, we recommend you upgrade it - our repository provides 0.10.0 since the release in October last year. Alternatively please switch to using the prosody-0.9 nightly packages to ensure you continue to get updates on the 0.9 branch.

NOTE for 0.10.x users: none of the security issues in this release affect 0.10. However 0.10.1 release will follow shortly with some bug fixes relevant to that branch.

Note that there is currently no deprecation plan for the 0.9 branch. We will continue to provide security and major bug fixes for the immediate future, although we do encourage you to upgrade to 0.10.

A summary of changes in this release:

Security

• Fix for compatibility with LuaSocket 3.0rc1 (fixes denial of service from remote)
• mod_register: Require encryption before registration if c2s_require_encryption is set (fixes #595)
• MUC: Ensure that elements which match our from are stripped (fixes #1055)

Fixes and improvements

• Compatibility fix with newer LuaSec 0.6 (fixes #781)
• mod_presence: Send probe once subscribed (fixes #794)
• mod_net_multiplex: Enable SSL on the SSL port (fixes #803)

Minor changes

• core.rostermanager: Add method for checking if the user is subscribed to a contact
• mod_saslauth: Log SASL failure reason
• mod_disco: Correctly set the 'node' attr (fixes #449)
• mod_bosh: Update session.conn to point to the current connection (fixes #890)
• net.dns: Simplify expiry calculation (fixes #919)
• mod_watchregistrations: Return the pointer to the root of the stanza, fixes #922.
• mod_disco: Add an account/registered identity on subscribed accounts, fixes #826.
• mod_welcome: Return the pointer to the root of the stanza, fixes a bug similar to #922.
• net.dns: Prevent answers from immediately expiring even if TTL=0 (see #919)
• mod_saslauth: Use correct varible name (thanks Roi)
• mod_c2s: Iterate over child tags instead of child nodes in stream error (fixes traceback from #987)
• mod_component, mod_s2s: Iterate over child tags instead of child nodes (can include text) in stream error (same as 176b7f4e4ac9)
• MUC: Always send subject message, even if it is empty (fixes #1053)
• MUC: fix the @from on in history replay (fixes #1054)
• MUC: Rename variable to make it clearer that it is the room JID and not the MUC host

Download

Source: prosody-0.9.13.tar.gz sig

Debian/Ubuntu and derivatives: Install 'prosody-0.9' from our package repository to receive nightly build 289 or higher.

If your Prosody is installed from your distribution, look to them for updates.

If you have any questions, comments or other issues with this release, let us know!

Yesterday I got my first results encrypting and decrypting OpenPGP messages using PGPainless, my fork of bouncy-gpg. There were some interesting hurdles that I want to discuss though.

GnuPG

As a first step towards working encryption and decryption, I obviously needed to create some PGP keys for testing purposes. As a regular user of OpenPGP I knew how to create keys using the command line tool GnuPG, so I started up the key creation by typing “gpg –generate-key”. I chose the key type to be RSA with a length of 2048 bits, as those settings are also the defaults recommended by GnuPG itself. When it came to entering user id information though, things got a little more complicated. GnuPG asks for the name of the user, their email address and a comment. XEP-0373 states, that the user id packet of a PGP key MUST be of the format “xmpp:juliet@capulet.lit”. My first thing to figure out was, if I should enter that String as the name, email or as a comment. I first tried with the name, upon which GnuPG complained, that neither name, nor comment is allowed to contain an email address. Logically my next step was to enter the String as the users email address. Again, GnuPG complained, this time it stated, that “xmpp:juliet@capulet.lit” was not a valid Email address. So I got stuck.

Luckily I knew that Philipp Hörist was working on an experimental OX plugin for Gajim. He could hint me to a process of “Unattended Key Generation“, which reads input values from a script file. This input would not be validated by GnuPG as strictly as when using the wizard, so now I was able to successfully create my testing keys. Big thanks for the help

Update: Apparently GnuPG provides an additional flag “–allow-freeform-uid”, which does exactly that. Allowing uids of any form. Using that flag allows easy generation and editing of keys with freely chosen uids. Thanks to Wiktor from the Conversations.im chat room

Bouncy-gpg

As a next step, I wrote a little JUnit test which signs and encrypts a little piece of text, followed by decryption and signature validation. Here I came across my next problem.

Bouncy-gpg provides a class called Rfc4880KeySelectionStrategy, which is used to select keys from the users keyring following a certain strategy. In my testing code, I created two keyrings for Romeo and Juliet and added their respective public and private keys like you would do in a real life scenario. The issue I then encountered was, that when I tried to encrypt my message from Juliet for Romeos public key, I got the error, that “no suitable key was found”. How could that be? I did some more debugging and was able to verify that the keys were in fact added to the keyrings just as I intended.

To explain the cause of this issue, I have to explain in a little more depth, how the user id field is formatted in OpenPGP.
RFC4880 states, the following:

A User ID packet consists of UTF-8 text that is intended to represent
the name and email address of the key holder.  By convention, it
includes an RFC 2822 [RFC2822] mail name-addr, but there are no
restrictions on its content.

A “mail name-addr” follows this format: “Juliet Capulet (The Juliet from Shakespear’s play) <juliet@capulet.lit>”.
First there is the name of the key owner, followed by a comment in parentheses, followed by the email address in angle brackets. The usage of brackets makes it unambiguous, which value is which, so all values are optional.
“<juliet@capulet.lit>” would still be a valid user id for example.

So what was the problem?
The user id of my testing key looked like this: “xmpp:juliet@capulet.lit”. Note that there are no angle brackets or parentheses around the text, so the string would be interpreted as name.
Bouncy-gpg’s Rfc4880KeySelectionStrategy however contained some code, which would check, whether the query the user entered to search for a key would be enclosed in angle brackets, to follow the email address format. In case it doesn’t, the code would add the angle brackets prior to executing the search. Instead of searching for “xmpp:juliet@capulet.lit”, the selection strategy would look out for keys with the user id “<xmpp:juliet@capulet.lit>”.
My solution to the problem was to create my own KeySelectionStrategy, which would leave the query as is, in order for it to match my keys user id. Figuring that out took me quite a while

Conclusions

So what conclusions can I draw from my experiences?
First of all, I’m not sure, if it is a good idea to give the user the ability to import their own PGP keys. GnuPGs behaviour of forbidding the user to add user ids which don’t follow the mail name-addr format will make it very hard for a user to create a key with a valid user id. (Update: Users can use the flag “–allow-freeform-uid” to generate new keys and edit existing ones with unconventional uids.) Philipp Hörist suggested that implementations of XEP-0373 should instead create a key for the user on the first use and I think I aggree with him. As a logical next step I have to figure out, how to create PGP keys using Bouncycastle

I hope you liked my little update post, which grew longer than I expected

Happy Hacking!

OpenPGP

OpenPGP (know as RFC4880) defines a format for encrypted and signed data, as well as encryption keys and signatures.

My main problem with the specification is, that it is very noisy. The document is 90 pages long and describes every aspect an implementer needs to know about, from how big numbers are stored, over which magic bits and bytes are in use to mark special regions in a packet, to recommendations about used algorithms. Since I’m not going to write a crypto library from scratch, the first step I have to take is to identify which parts are important for me as a user of a – lets call it mid-level-API – and which parts I can ignore. You can see this posting as kind of an hopefully somewhat entertaining piece of jotting paper which I use to note down important parts of the spec while I go through the document.

Lets start to create a short TL;DR of the OpenPGP specification.
The basic process of creating an encrypted message is as follows:

• The sender provides a plaintext message
• That message gets encrypted with a randomly generated symmetric key (called session key)
• The session key then gets encrypted for each recipients public key and the resulting block of data gets prepended to the previously encrypted message

As you can see, an OpenPGP message consists of multiple parts. Those are called sub-packets. There is a pretty respectable number of sub-packet types specified in the RFC. Many of them are not very interesting, so lets identify the few which are relevant for our project.

• Public-Key Encrypted Session Key Packets
  Those packets represent a session key encrypted with the public key of a recipient.
• Signature Packets
  Digital signatures are used to provide authenticity. If a piece of data is signed using the secret key of the sender, the recipient is able to verify its origin and authenticity. There is a whole load of different signature sub-packets, so for now we just acknowledge their existence without going into too much detail.
• Compressed Data Packets
  OpenPGP provides the feature of compressing plaintext data prior to encrypting it. This might come in handy, since encrypting files or messages adds quite a bit of overhead. Compressing the original data can compensate that effect a little bit.
• Symmetrically Encrypted Data Packets
  This packet type represents data which has been encrypted using a symmetric key (in our case the session key).
• Literal Data Packets
  The original message we want to encrypt is referred to as literal data. The literal data packet consists of metadata like encoding of the original message, or filename in case we want to encrypt a file, as well as – of course – the data itself.
• ASCII Armor (not really a Packet)
  Encrypted data is represented in binary form. Since one big use case of OpenPGP encryption is in Email messaging though, it is necessary to bring the data into a form which can be transported safely. The ASCII Armor is an additional layer which encodes the binary data using Base64. It also makes the data identifiable for humans by adding a readable header and footer. XEP-0373 forbids the use of ASCII Armor though, so lets focus on other things instead

Those packet types can be nested, as well as concatenated in many different ways. For example, a common constellation would consist of a Literal Data Packet of our original message, which is, along with a Signature Packet, contained inside of a Compressed Data Packet to save some space. The Compressed Data Packet is nested inside of a Symmetrically Encrypted Data Packet, which lives inside of an OpenPGP message along with one or more Public-Key Encrypted Session Key Packets.

Each packet carries additional information, for example which compression algorithm is used in the Compressed Data Packet. We will not focus on those details, as we assume that the libraries we use will already handle those specifics for us.

OpenPGP also specifies a way to store and exchange keys. In order to be able to receive encrypted messages, a user must distribute their keys to other users. A key can carry a lot of additional information, like identities and signatures of other keys. Signatures are used to create trust networks like the web of trust, but we will most likely not dive deeper into that.

Signatures on keys can also be used to create key hierarchies like super keys and sub-keys. It still has to be determined, if and how those patterns will be reflected in my code. I can imagine it would be useful to only have sub-keys on mobile devices, while the main super key is hidden away from the orcs in a bunker somewhere, but I also think that it would be a rather complicated task to add support for sub-keys to my project. We will see

That’s it for Part 1 of my sighting of the OpenPGP RFC.

Happy Hacking!

During preparations for my GSoC project, I’m finding first traces left by developers who dealt with OpenPGP before. It seems that Florian was right when he noted, that there is a lack of usable higher level Java libraries as I found out when I stumbled across this piece of code. On the other hand I also found a project which thrives to simplify OpenPGP encryption as much as possible. bouncy-gpg – while apparently laying its focus on file encryption and GnuPG compatibility – looks like a promising candidate for Smacks OX module. Unfortunately its code contained some very recent Java features like stream semantics, but I managed to modify its source code to make it compatible down to Androids API level 9, the version Smack is currently targeting. My changes will eventually be upstreamed.

While my next target is now to create a very basic prototype of OX encryption, I’m also reading into OpenKeychains OpenPGP API. It would be very nice to create a universal interface that allows for OX encryption using multiple backends – BouncyCastle on pure Java systems and SpongyCastle / OpenKeychain on Android.

During my work on OX providers for Smack, I stumbled across an interesting issue. When putting a body element as a child into an signcrypt element, the body did not include its namespace, as it is normally only used as child of the message element. Putting it into a signcrypt element made up a special edge case. When a Provider tries to parse the body element, it would falsely interpret the missing namespace as the one of the parent element. Florian provided the solution to this problem by modifying the “toXML()” method of all elements to require an enclosing namespace. Now the body is able to include its namespace in the XML in case the enclosing namespace is different from “jabber:client”.

Happy Hacking!

Welcome to the 3rd edition of the XMPP newsletter.

Jeff Becker has written a howto called New life for XMPP. Build your own decentralized messenger! which focuses on using the I2P anonymous network layer instead of using a registered domain name.

Peter Waher has published his book "Mastering Internet of Things", available from Packt and Amazon.

Georg Lukas has written a post Freedom and Anonymity on XMPP in which he addresses concerns around his Jabber Spam Fighting Manifesto and its possible effects on issues of privacy and free speech.

The USA's National Institute of Standards and Technology (NIST) released a draft report on cybersecurity or the Internet of Things (IoT). Daniel Wisnewski from Tigase has written an analysis with focus on using XMPP for IoT.

Tigase recently moved their xmpp.cloud service to Amazon Web Services and Daniel wrote an article on how using AWS helped them optimize memory usage in the Tigase HTTP API.

Software releases

Servers

• Ejabberd 18.04 has been released, it includes bugfixes and a few improvements.

• Less than a month after MetronomeIM 3.8, versions 3.8.1, 3.8.2, and 3.8.3 have followed, bringing improvements such as MAM, SIFT, avatars and GDPR.

• Erlang Solutions made a new 2.2 release of MongooseIM, subtitled The Global Server, as it supports certificate based authentication (XEP-0178), stable Global Distribution that connects multiple servers/clusters worldwide under the same domain name, a Jingle/SIP proxy, an important security fix, hidden components and more.

Clients

• Less than a month after the symbolic version 1.0.0, Gajim 1.0.1 and Gajim 1.0.2 have been released. Version 1.0.1 improves MAM support, adds image previews in the file chooser dialog and includes many smaller fixes and improvements. Version 1.0.2 correctly reloads plugins, saves history export with utf8 encoding, doesnt allow plain BOSH by default, and fixes many bugs.

• ChatSecure releases version 4.3.0, which is able to catch up on discussions that happened while it was offline and supports #OMEMO encryption.

• In its on-going series of concise blog posts, Monal IM developer follows up on MAM development, as well as announces a future implementation of XEP-0184: Message Delivery Receipts.

Libraries

• Smack 4.2.4 has been released, adding support for XEP-0394: Message Markup, XEP-0382: Spoiler messages, XEP-0372: References, XEP-0392: Consistent Color Generation, and bringing even more fixes and improvements.

• MatriX vNext version 2.0 has been released. It is a cross platform XMPP SDK for the full .NET Framework, .NET Core and Mono.

XMPP videos:

Daniel Gakwaya has been making various XMPP-related videos the last while, some of them we've linked to in previous newsletters.

• XMPP Core Explained: Introduction
• XMPP Core Explained : XMPP Architecture
• XMPP Tutorial: The Friendly Introduction
• XMPP Android Chat App Tutorial Step by step
• XMPP WhatsApp like Android Chat App With Smack

This ejabberd 18.04 release includes bugfixes, and a few improvements.

New configuration options

New ‘access_register’ option for mod_muc

This option specifies who is allowed to register nickname within the Multi-User Chat service. The default is all for backward compatibility, which means that any user is allowed to register any free nick.

New ‘include_sender’ and ‘include_body’ options for mod_push

If one or both of them are set to ‘true’, a urn:xmpp:push:summary form with the enabled field(s) is included in push notifications that are generated for messages with a body.

The ‘include_body’ option can instead be set to a static text. In this case, the specified text will be included in place of the actual message body. This can be useful to signal the push service whether the
notification was triggered by a message with body (as opposed to other types of traffic) without leaking actual message contents.

SQL schema change

Pubsub creation/modification columns in pubsub_item table now use varchar. This minor change will speedup requests on pubsub_item table. See upgrade details in the upgrade note.

Changes

• Don’t produce a crash dump during intentional exit
• ejabberdctl: fix parameter parsing
• New hook ‘component_send_packet’ for sending packet from component
• gen_mod: Carefully validate options list
• gen_mod: Support global module processes
• gen_mod: Remove frontend process support
• gen_mod: Don’t crash on invalid module’s sub-options
• config: move section about direct-tls for c2s just under regular c2s config
• fast_tls: Clear cache on configuration reload
• http: Add support for PATCH http method
• mod_client_state: Add ‘csi_activity’ hook
• mod_http_upload: Accept characters of any script
• mod_http_upload: Add MIME type for M4A files
• mod_mam: Add commands for cleaning up archives for a given user
• mod_muc: Let a MUC room to route presences from its bare JID
• mod_muc: Introduce new mod_muc option: access_register
• mod_muc_room: Add stubs for affiliation-specific backend callbacks
• mod_muc_log: Fix Code format when logging a MUC room kick/ban
• mod_multicast: Improved
• mod_push: New options include_sender and include_body
• mod_push: Don’t notify on stream errors
• mod_push_keepalive: Reset timeout on messages only
• mod_roster: Use ‘lserver’ for configuration lookup
• mod_vcard_ldap: Fix returning value from mod_vcard_ldap’s search() callback
• mod_pubsub: Fix notification payload generated by pubsub
• mod_pubsub: Improve pubsub#itemreply implementation
• mod_pubsub: PubSub purge_node must use a transaction
• Utils: Use httpc directly instead of using p1_http wrapper
• Rest: Add flexibility on rest url config
• SystemMonitors: Get rid of useless memory/disk usage warnings
• WebSocket: Pass access option from websocket to c2s

Feedback

As usual, the release is tagged in the Git source code repository on Github.

The source package and binary installers are available at ProcessOne.

If you suspect that you’ve found a bug, please search or fill a bug report on Github.

The new Mac build with the MAM preferences screen is now up.  Look for it under the Account menu .

we are thrilled to announce MatriX vNext 2.0

main changes in 2.0 are:

• minor API changes which force major version bump (semver)
• Direct TLS support (XEP-0368)
• netstandard 2.0 support
• new NameResolver wich allows to specify IP addresses of the XMPP server manual
• new Matrix.Extensions package with extensions and helper functions
• myget feed for latest dev builds

There is a new website for MatriX vNext and the documentation at:
https://matrix-xmpp.io/

All source code is available on Github now at:
https://github.com/matrix-xmpp/matrix-vnext

There is a WPF example client based on MatriX vNext available on Github here: https://github.com/matrix-xmpp/matrix-client

I will have a new MAM preferences screen in the next Mac build.

While every MongooseIM release comes with important improvements, sometimes they are more relevant for certain groups of users. In MongooseIM 2.2 we present 3 major features: SASL EXTERNAL authentication mechanism, stable Global Distribution, and Jingle/SIP proxy.

All of them are especially beneficial to larger deployments or big companies.

They often already provide certificate-based authentication to their users, so with SASL EXTERNAL it is no longer required to introduce new passwords or tokens to your existing system.

Also, when they hit a certain cluster scaling limit, they need to distribute a service to several data centers. In order to retain user experience, Global Distribution comes into play.

The third element, Jingle/SIP proxy, will be appreciated by VoIP app owners who would like to incorporate MongooseIM and integrate it with existing clients and components.

If you’d like to learn more, please keep reading.

One more thing: I think we owe a word of explanation for the community members who were tracking our repository and our responses to issues on GitHub. We were on track to release MongooseIM 3.0, but it turned out that certain important Pull Requests required further work. We didn’t want to keep you waiting, so the new version is here anyway. Only with different version number increase.

Welcome to MongooseIM 2.2!

Authentication with certificates

Typical XMPP authentication involves a password or a token that is sent to the server. There are several SASL (Simple Authentication and Security Layer) mechanisms with SCRAM-SHA-1 being the recommended one.

In 2006, a set of recommendations was published as XEP-0178. They describe best practices for SASL EXTERNAL mechanism usage. It is actually a pretty mature extension, but it gained extra attention recently when more and more companies wished to use certificate-based authentication.

SASL EXTERNAL implementation in MongooseIM 2.2 follows the aforementioned XEP and tightly integrates with TLS encryption used for connection. It means that client certificate used for securing the stream may be reused to log the client in. It is not only a very secure method, but also avoids introducing concepts of passwords and tokens in systems where they are not actually needed.

Stable Global Distribution

All of you know what mobile network and landline are. The former allows you to call everyone in the world, as long as they carry their device with them, always with the same number. The latter requires the recipient to be present at a specific location in order to receive a call. What is more, you actually have to know where they are, as landline phone numbers (at least usually) include prefixes assigned to certain districts or cities.

I’ve included a reminder of all these attributes to explain a difference between Global Distribution and classic XMPP Federation. The former is an XMPP cellular network and the latter is an XMPP landline. GD is a custom extension developed by the MongooseIM team, exclusive to our server. With GD enabled, your clients no longer need to be aware of the recipient’s exact location. They may be connected to any cluster.

As you may guess, message routing in this case is more expensive than the old model. Actually, it requires a distributed routing table. The current solution may be used with a Netflix Dynomite layer on top of Redis.

The teams behind smaller apps may rest assured - when your solution grows, it will be possible to enable Global Distribution later, for existing cluster(s). You don’t need to worry about the Dynomite and Redis overhead already. :)

Global Distribution module was already present and mentioned in the 2.1.1 release. It was considered highly experimental back then but we’ve received many reports about bugs and possible improvements. We’ve resolved all of them, so in MongooseIM 2.2 we consider it stable. It is still not fully compatible with some extensions, as e.g. users migrating between clusters could lead to fragmented message archive. Nevertheless, it’s core purpose - routing stanzas between users and components in different clusters - works very well and features several mechanisms to prevent message loss and ensure efficiency.

Jingle/SIP proxy

Many VoIP applications rely on SIP - a protocol with good support and wide range of software implementing it. It has its shortcomings though. First of all, it is difficult to extend and is focused on P2P session management. Secondly, it does not use long-lived sessions.

XMPP suffers from neither of them, but usually you can’t simply turn off old parts of your system and enable the new one in order to migrate. A transition period is not uncommon. In some cases, SIP-exclusive apps might require really long maintenance, especially in environments where hardware and software are not updated that often.

Thanks to MongooseIM 2.2, when you decide to switch to XMPP in your application, you’ll be able to seamlessly connect SIP and XMPP worlds. Our server may translate essential SIP packets to Jingle stanzas and back. Please check documentation for mod_jingle_sip module for further details.

Jingle/SIP switch feature is sponsored by Sonetel.

A tutorial for this feature will be available soon!

Important security fix for error routing

This patch deserves a separate section as it is especially important for deployments based on previous MongooseIM versions that use the mod_event_pusher_push extension. A malicious user may send a prepared stanza that eventually could lead to an endless routing loop that crashes the MongooseIM node due to the out of memory exception.

It is highly recommended to update every deployment. Those using heavily customised server versions, that are challenging to merge, should at least apply PR #1800.

Misc. technical improvements & changes

It’s always cool to have a strong highlights in a release but much more always happens behind the scenes. MongooseIM 2.2 includes many smaller changes or the ones relevant to developers rather than users and devops.

Header files refactoring

MongooseIM header files underwent significant refactoring, including split into smaller files and moving definitions to more appropriate places. Here are some examples: ejabberd.hrl has been renamed to mongoose.hrl All error macros from jlib.hrl have been transformed into mongoose_xmpp_errors.erl module. All namespace definitions from jlib.hrl have been moved to mongoose_ns.hrl JID-related type definitions have been moved to jid.erl

For a full diff, please consult PR #1570

Mongoose Services

Classic MongooseIM extension modules are started for every served XMPP domain, as configured in a hosts option in a config file. In most cases it is a perfectly valid approach, e.g. in case of roster or privacy lists support. It does not apply though to features that should be started only once, e.g. Global Distribution (because it strictly operates only with two domains: global and local one) or mod_admin_extra.

Until 2.2, various hacks were necessary to ensure single init for these extensions, such as: Custom ETS table to count “reference/init count” Initialisation only for specific domain Completely ignoring the problem :)

In order to resolve this problem, Services are introduced in MongooseIM 2.2. These are very similar to modules but are always started before them and only once per node. When an extension depends on a service, it is impossible to provide a default configuration to use (as opposed to module dependencies) so required services must always be properly configured. They are prefixed with service_, instead of mod_.

For now, only mod_admin_extra has been converted into service_admin_extra. More extensions will follow, most probably in 3.0’s successor.

Hidden components

Sometimes XMPP components connected to the server do not interact directly with ordinary clients but they are listed in Service Discovery result anyway. It is inconvenient if the deployment uses many of them and the Disco response to a client is not only big but simply cluttered.

It is now possible to open a separate endpoint for such components. With proper option enabled, they will act as usual but won’t show up in Disco results sent to the clients. They are “hidden components”.

Please note that other services may still discover them. Also, the server won’t prevent clients from contacting hidden components, so it does not increase security but rather efficiency and makes frontend apps easier to maintain (if they rely on Service Discovery much).

Changelog

Please feel free to read the detailed changelog, where you can find a full list of source code changes and useful links.

Contributors

Special thanks to our contributors: @igors @jacksgt @sstrigler @GalaxyGorilla @varnerac!!

What’s next?

MongooseIM 3.0 is going to be released on May 22nd. It will bring exciting improvements that all MongooseIM users will appreciate for sure.

Inbox has been present in many applications for a couple of years already and our experience with various implementations resulted in an extension that covers common use cases for conversations view. It is undergoing last reviews and improvements and will be included in 3.0.

Erlang terms, while very practical for MongooseIM developers, were never really intuitive for administrators and devops. In order to make their lives easier, we’re going to change the config file format to a completely new one. TOML is the most promising candidate.

We’re experimenting with a new XML parser. The current one is built on top of expat and the new one uses RapidXML. Initial benchmarks indicate significant improvements in raw performance and the new implementation is being polished.

Obviously, the 3.0 release will be one of the most important milestones in MongooseIM history!

Test our work on MongooseIM 2.2 and share your feedback

Help us improve the MongooseIM platform:

1. Star our repo: esl/MongooseIM
2. Report issues: esl/MongooseIM/issues
3. Share your thoughts via Twitter: twitter.com/MongooseIM
4. Download Docker image with new release
5. Sign up to our dedicated mailing list to stay up to date about MongooseIM, messaging innovations and industry news.
6. Check out our MongooseIM product page for more information on the MongooseIM platform.

I’m very happy to announce that once again I will participate in the Summer of Code. Last year I worked on OMEMO encrypted Jingle Filetransfer for the XMPP client library Smack. This year, I will once again contribute to the Smack project. A big thanks goes out to Daniel Gultsch and Conversations.im, who act as an umbrella organization.

My new project will be an implementation of XEP-0373 and XEP-0374 OpenPGP for XMPP + Instant Messaging. The projects description can be found here.

Now I will enjoy my last few free days before the hard work begins. I will keep you updated

Happy Hacking!

I was trying to figure out why MAM wasn’t working on the server that I used. I didn’t know that some servers disable this feature and you need to enable it.  I guess I need to add a UI for this.