libolm is deprecated

[gmacon]

The Matrix developers have deprecated libolm. I haven't seen an official statement about why, but, based on the timing, it seems that this is because there's a vulnerability of some sort with a coordinated disclosure deadline of August 14. The official replacement for libolm is vodozemac, but it's written in Rust and they don't appear to have any official C API that I could find.

I see you already have a pure-Go implementation of the Olm protocol, so my suggestion would be that you switch to that (and address the vulnerability, whatever it is, if it's a protocol vulnerability instead of an implementation flaw in libolm).

As a side point, and please let me know if there's a better place to ask this question: Has there been a cryptographic audit of goolm?

[tulir]

There's no new vulnerability in libolm, it's just that the crypto primitive implementations aren't resistant to side-channel attacks. It's not a secret, it's mentioned in the deprecation notice and has technically always been documented in the libolm repo (https://gitlab.matrix.org/matrix-org/olm/-/blob/master/lib/crypto-algorithms/README.md)

Honestly soatok's obnoxious behavior makes me want to ignore the whole problem, but that's obviously not a very constructive approach, so we'll switch away from libolm at some point. Not yet sure if the result will be finishing goolm or adding vodozemac support, but definitely one of the two.

Beeper will probably get goolm audited after it's ready.

[gmacon]

That's very interesting, thanks for the information! I guess I was reading too much into the "watch this space" notice from soatoak; I was expecting a new memory-safety bug leading to RCE or something along those lines that's actually a serious problem.

[tulir]

FTR the full blog post has now been published: https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/

My comment above still applies, but at least the blog post isn't pure fearmongering like the earlier toot.

[gmacon]

I read the blog post, and I think that the original message was probably written with a level of urgency appropriate for the counterfactual where the EdDSA nonce observation was actually an issue and not just misreading the code.

[tulir]

Yeah it would've been appropriate for that, except the EdDSA thing was found to be incorrect on May 17th according to the timeline, while the toot was posted on July 31st

[sumnerevans]

I just merged a PR to allow goolm and libolm to exist side-by-side: #211. This means that we can test libolm and goolm against one another and make sure that goolm adheres to spec.

[k4lipso]

I wonder what the status of this issue is. From the comments here, it is not clear if or when we can expect a migration away from libolm. I see that @sumnerevans has been working on a goolm-side-by-side branch—are there any results or discoveries worth sharing?

On NixOS, libolm is marked as insecure (NixOS/nixpkgs#334638), which means that users installing mautrix-go or any package that depends on it encounter the error: Package ‘olm-3.2.16’ in [...] is marked as insecure, refusing to evaluate. I understand that this may be outside the scope of mautrix-go itself, but I want to emphasize that the user experience of mautrix-go is suffering in some cases, due to its dependency on libolm.

[sumnerevans]

No updates of note. No timeline, either.

It is my opinion that NixOS did the wrong thing in NixOS/nixpkgs#334638. It should never have been marked as vulnerable. I just have nixpkgs overrides that allow olm, and it works fine.