depends on deprecated library sodiumoxide

[jonassmedegaard]

The sodiumoxide project is now deprecated: sodiumoxide/sodiumoxide@5bb1dfd

[tasn]

I think it's not deprecated in terms of DO NOT USE, but rather: it's now feature complete, no?

[jonassmedegaard]

Right, that is my understanding as well.

I am no crypto expert, but seem to read between the lines, however, that what the author describes as having "vastly changed" includes maturity of implementations in native Rust, which I would expect to have both size, speed, and stability improvements.

Seems the Dalek libraries (and crates based on those) are the most popular in the Rust community nowadays.

[tasn]

The problem is that we can't only care about quality, but we also need to care about compatibility with the algorithms we use (libsodium ones).

Dalek looks great though! I wonder if there's a sodium compatibility layer!

[jonassmedegaard]

Perhaps this: https://crates.io/crates/crypto_box

[tasn]

Main questions are:

1. is it worth it?
2. Compatibility.

[Xiretza]

sodiumoxide is now completely archived and will thus no longer receive security fixes; it should be replaced.

[tasn]

:|

OK, I'll try to find some time to take a look, thanks!

[barathrm]

I'm looking into finally upstreaming libetebase into openSUSE, and just discovered this one again during the automated cargo audit that's run.

Friendly bump 🤗

[tasn]

There's nothing wrong with sodiumoxide I believe, it's just "no longer developed". I don't know what it actually means in terms of security, but given that it's just a thin wrapper around libsodium, I'm not that concerned. It's going to be quite a bit of work changing to a new implementation, which I don't have time for unfortunately. Especially given the questionable benefits.

[mainrs]

sodiumoxide is now completely archived and will thus no longer receive security fixes; it should be replaced.

This does not seem to be the case:

https://github.com/sodiumoxide/sodiumoxide/blob/3057acb1a030ad86ed8892a223d64036ab5e8523/README.md?plain=1#L3-L5

This seems to mean that new API surface in libsodium will not be implemented in the crate. But security fixes that arise will be fixed accordingly on the already existing API surface.

[Xiretza]

That message is from before the repo was archived.

[tjanez]

I just hit this issue when talking to Fedora Rust SIG about packaging etebase-rs for Fedora.

Fabio Valentini warned that (among all etebase-rs' depencencies):

The only problematic one I see here is sodiumoxide. This project has been
abandoned and probably really shouldn't be used any longer ... all others
are already packaged for Fedora as far as I can tell.

I think this makes it a blocker for packaging it in its current state.

When I asked Fabio Valentini regarding possible alternatives, he replied:

It depends on which functionality from libsodium they need.
They already depend on OpenSSL, I would just use that if possible.

If OpenSSL doesn't provide everything they need, the RustCrypto
project provides implementations for a lot of things:
https://github.com/RustCrypto

[tasn]

The challenge is that the change to either is a complete rewrite of the underlying crypto (and making sure that everything is backwards compatible). It's not a simple change unfortunately. :(

[Skycoder42]

Another option could be to depend on just libsodium (C library) and create rust bindings for only the APIs needed as part of this project. This still would be quite some work, but would not need any rewrites of application code and ensure compatibility

[tjanez]

Another option could be to depend on just libsodium (C library) and create rust bindings for only the APIs needed as part of this project. This still would be quite some work, but would not need any rewrites of application code and ensure compatibility

Could this be a viable path forward?

It would be really great if we could provide etebase-rs and Evolution EteSync plugin in Fedora's upstream repos. And as far as I understand, the sodiumoxide dependency is the only blocker to this.

The user experience with the 3rd party COPR repo has been less than ideal (see: https://gitlab.gnome.org/GNOME/evolution-etesync/-/issues/20), and it would be much better if users could just install it directly from Fedora's repos.