mautrix-{meta,signal,whatsapp}: build with goolm

[gmacon]

Description of changes

After olm gained knownVulnerabilities in #334638, build these bridges using the pure-Go goolm library instead of libolm bindings. I also tried converting mautrix-discord, but it failed to build for what appears to be an upstream reason, but I saw no reason to block the other three. The other mautrix-* bridges in nixpkgs are Python bridges, and I didn't look into building those without olm.

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]

Tagging @sumnerevans here as I expect he’ll have opinions about this – per #336052 (comment) apparently goolm has known issues with these bridges.

[niklaskorz]

I think this should be an option for now, i.e., add it as a package argument so it's easy to override. I'm impartial about which to make the default (libolm has the vulnerability, goolm is potentially not adhering to the spec yet and hasn't been audited).

[gmacon]

I think this should be an option for now, i.e., add it as a package argument so it's easy to override.

Do you have any preferences about what shape the option should take? Is it withGoolm ? false?

[sumnerevans]

We (Beeper) tried to use goolm in our next-generation Android client and ran into weird issues. It's not entirely clear whether the issues were due to goolm itself or the way that we were using the library. We ended up just using libolm to reduce the number of variables that could be causing our issues.

I definitely think compilation with goolm should be added as a disabled option for now. Selfishly, it would be great if some people started testing it out more in production and reported any issues with it.

[dotlambda]

Selfishly, it would be great if some people started testing it out more in production and reported any issues with it.

I doubt any of those issues would be fixed.
The upstream repo has only seen a total of 16 commits by a single author.
There's also nothing that indicates it's more secure than libolm. Rather the opposite.

[emilazy]

Mautrix uses their own fork.

[gmacon]

Ok, here we go. OfBorg and Hydra won't build these as-is, but I tested the builds with commands like

nix build --impure --expr 'let p = import ./. {}; in p.mautrix-whatsapp.override { withGoolm = true; }'

I intend to use these options for my self-hosted Beeper bridges, and I'll report any issues I run into.

[niklaskorz]

Tested the whatsapp and signal bridges, both seem to work just fine with goolm enabled

Edit: looks like replies on the whatsapp bridge are broken with goolm
Edit 2: same on the Signal bridge, all incoming messages are broken with goolm. Nonetheless I'm not opposed to merging this as it's opt-in right now.

[Ma27]

Given the current issues with this flag we should add a warning as comment above. Given that these flags aren't discoverable at all, you'll see the warning when you learn about the flag (by reading the expression).

[gmacon]

How about:

This option enables the use of the goolm library instead of libolm for end-to-end encryption. Using goolm is not officially supported by the mautrix developers, but they are interested in people trying it out and reporting any issues they run into.

@sumnerevans , I'm particularly interested in your feedback here to make sure that I don't misrepresent what Beeper wants to promise/request.

[sumnerevans]

We marked it as experimental as of https://github.com/mautrix/go/releases/tag/v0.17.0, so maybe:

This option enables the use of an experimental pure-Go implementation of the Olm protocol instead of libolm for end-to-end encryption. Using goolm is not recommended by the mautrix developers, but they are interested in people trying it out in non-production-critical environments and reporting any issues they run into.

Given the issues that people have already mentioned, I think we should warn people about using this in production-critical environments.

[Ma27]

Approach is OK for me.
Haven't tried the goolm variant out so far, but @sumnerevans having approved this is OK change-wise, so let's merge.

[github-actions]

Successfully created backport PR for release-24.05:

• [Backport release-24.05] mautrix-{meta,signal,whatsapp}: build with goolm #338805