libolm is now deprecated.
olivia-fox opened this issue · comments
In about two weeks there is going to be a disclosure of unfixed vulnerabilities in libolm, which in response has been deprecated by the Matrix developers in favour of vodozemac. Is migrating to vodozemac something that might be possible?
I just had a discussion about this in https://matrix.to/#/#src_prepare:matrix.org .
To sum up:
- vodozemac's official bindings are unmaintained and doesn't compile at all.
- matrix-rust-sdk has a uniffi binding but uniffi itself does not generate c++ bindings.
- there is uniffi-bindgen-cpp but I failed to use it, apparently because it does not support async functions, while matrix-rust-sdk has async functions. https://github.com/NordSecurity/uniffi-bindgen-cpp?tab=readme-ov-file#unsupported-features
- also, matrix-rust-sdk seems to dictate some way we process the data, and is simply not a drop-in replacement for libolm.
I will likely am fixing vodozemac-bindings. See https://lily-is.land/kazv/vodozemac-bindings for the code and https://iron.lily-is.land/project/view/10/ for the work board. Any help is welcome.
It may or may not end up getting upstreamed.
I guess that's the mentioned disclosure: https://soatok.blog/2024/08/14/security-issues-in-matrixs-olm-library/
Just for context, while moving to vodozemac is possible, we haven't decided if that is something we want to do, since it introduces quite some packaging complications. Additionally those "security issues" are things, that have been documented in libolm for years already and passed 2 separate audits (with remarks but low impact to how it is used in Matrix). See https://gitlab.matrix.org/matrix-org/olm/-/tree/master/lib/crypto-algorithms?ref_type=heads for example.
Just because someone writes a blog post, don't start jumping to conclusions. So far there is little evidence that side channel attacks on libolm are abusable by a remote attacker, simply because Matrix gives limited options to trigger crypto operations remotely, that can be accurately timed. As such moving to vodozemac is much more a concern of if we trust it to be maintained in the future, if it provides all the functions we use from libolm (it currently does not, but we could implement the missing bits ourselves) and if we want a rust library as a required dependency.
I don't consider those "security issues" to be particularly relevant to Nheko, unless someone can show me something I missed.
Regardless of the criticality / severity of the CVEs this time around, using a library which is deprecated / does not receive security patches is just asking for trouble.
While it is true that libolm won't receive security patches from the Matrix Foundation anymore, we probably have some time to see how its maintenance situation turns out. It might be the case that a community decides it is worth maintaining libolm. If that isn't the case, a move to vodozemac or another alternative does make sense. But libolm hasn't received significant patches for years already. Vodozemac on the other hand recently did receive security fixes, some of them for the issues still affecting libolm, others for issues unique to the rust ecosystem (dependencies changed default flags which disabled some security features in vodozemac). So from that perspective I don't see a pressing need to hurry with a decision and we can take some time to see, where the ecosystem moves. Moving to vodozemac would be a significant change and could introduce security issues by itself if the port is badly done. As could be buggy C++ bindings for it.
It might be the case that a community decides it is worth maintaining libolm.
I think the problem does not lie in whether someone wants to do it, but rather whether someone has the resources (proficiency, funds to audit) to do it. While I certainly do not want rust to be the only implementation, I do not have the resources to keep libolm going.
Also a vulnerability is a vulnerability is a vulnerability.
I think that the guilty crypto primitives can be replaced for proper OpenSSL calls, as the PR fixes: https://gitlab.matrix.org/matrix-org/olm/-/merge_requests/24
FYI, in the Nix package manager, olm is now marked as insecure, preventing a straightforward installation of nheko. While there is an easy installation workaround for Nix, it might not be that easy for other distributions (should they decide to take similar measures).