olm: update vulnerability description

[sumnerevans]

Description of changes

Since the known vulnerability was added, additional information has been
published by upstream about why they believe the vulnerability to not be
exploitable over the network:
https://matrix.org/blog/2024/08/libolm-deprecation/

This commit updates the text of the vulnerability warning with
additional information from the blog post as well as a link to the blog
post.

Signed-off-by: Sumner Evans [email protected]

Things done

• Built on platform(s)
  • x86_64-linux
  • aarch64-linux
  • x86_64-darwin
  • aarch64-darwin
• For non-Linux: Is sandboxing enabled in nix.conf? (See Nix manual)
  • sandbox = relaxed
  • sandbox = true
• Tested, as applicable:
  • NixOS test(s) (look inside nixos/tests)
  • and/or package tests
  • or, for functions and "core" functionality, tests in lib/tests or pkgs/test
  • made sure NixOS tests are linked to the relevant packages
• Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
• Tested basic functionality of all binary files (usually in ./result/bin/)
• 24.11 Release Notes (or backporting 23.11 and 24.05 Release notes)
  • (Package updates) Added a release notes entry if the change is major or breaking
  • (Module updates) Added a release notes entry if the change is significant
  • (Module addition) Added a release notes entry if adding a new NixOS module
• Fits CONTRIBUTING.md.

---

Add a 👍 reaction to pull requests you find important.

[emilazy]

Thanks. I am nervous about adding more wording in our own voice to this message since the whole matter has become so controversial and the message is already so long; I would prefer to keep it brief and avoid spending much copy on any specific post so that users get the necessary background and can make their own assessments from the links. I think that “It is not known that the issues can be exploited over the network in practical conditions.” is still accurate – it is, thankfully, not known that that can be done – but we can mention that upstream does not consider that likely to change. I was planning to replace the TWIM link with this statement since it supersedes it in my view (just as I replaced the HN comment with the TWIM link).

[emilazy]

Looks good to me; I’ll let @LeSuisse take a look before merging. I’ll also incorporate this into the backport PR. Thanks!

[LeSuisse]

Looks good to me too.

(And yeah we finally have an official statement to link to 🎉 )

[leo60228]

The wording in this PR seems much stronger than upstream's statements to me:

Upstream [...] has stated that the library should not be used going forward

vs.

Given the above, in the context of Matrix, libolm is currently safe to use in a practical sense (with the above caveats). However, we strongly encourage all app developers to chart a path away from libolm in favour of vodozemac.

I definitely don't see this as implying that they expect distributors or end users to take action, and marking the packages as vulnerable has the IMO fairly severe consequence of resulting in them not being built by Hydra.

[emilazy]

The wording is inherited from #334638, and is based on the upstream statement in the libolm repository:

As such as of July 2024, libolm is now officially deprecated - please do not use it going forwards. The Matrix cryptography team sadly does not have bandwidth to maintain both vodozemac and libolm, and all of our maintenance effort will go into vodozemac.

so it’s almost a direct quote. Not much to say beyond that as all sides were pretty thoroughly hashed out in the original PR.

[emilazy]

FWIW I don’t have any objection to building libolm on Hydra (we have a mechanism for exceptions to the blanket exclusion of marked‐insecure packages from Hydra builds), but I think we concluded there was no need to because none of the reverse dependencies are particularly heavy builds. If there are clients that would be particularly painful for users to build (maybe Nheko, since it’s C++?), then it seems reasonable to consider adding olm to the list of exceptions.

[rnhmjoj]

If there are clients that would be particularly painful for users to build (maybe Nheko, since it’s C++?), then it seems reasonable to consider adding olm to the list of exceptions.

Exactly: the nheko developers said they don't have immediate plans to switch to vodozemac; no one has shown how to practically exploit these "vulnerabilities" and building nheko is quite resource intensive. I'm going to add an exception.

[emilazy]

An exception for the Hydra permitted insecure packages list would be okay in my view. That means it can still be built on Hydra but the user has to override the warning to use it. Hiding the message entirely on an ad-hoc basis is not.

[rnhmjoj]

An exception for the Hydra permitted insecure packages list would be okay in my view. That means it can still be built on Hydra but the user has to override the warning to use it. Hiding the message entirely on an ad-hoc basis is not.

So, basically here we have both the upstream developers of the library and the client saying these vulnerabilities are basically non-issue; yet we are breaking setups unless they read a super technical wall of text, follow the instructions and accept the shame of having vulnerable software in their computer.

Okay, I guess this is useful if you're someone like Ed Snowden, but for the average Joe, it's a terrible user experience.

[emilazy]

(Replied in #341831 (comment).)