jan-schreib / monocypher-rs Goto Github PK

I've noticed you have yanked all older versions of monocypher-rs, but this is not always considered a good practice in rust.

ring used to do it, but it caused lots of discussions, resulting in rust-lang/crater moving from ring to openssl (rust-lang/crater#394) and ring starting yanking only known-vulnerable versions. See this comment from pietroalbini (member of many rust teams). It's a bit subjective, but my personal opinion is similar, crates should be yanked only when there's a semver compatible release available.

Related discussions:

• https://old.reddit.com/r/rust/comments/ctayew/rust_crypto_developers_please_stop_the_yanking/
• https://old.reddit.com/r/rust/comments/90cpjg/security_advisory_for_smallvec_calling_insert/e2pmxhi/

On an unrelated notes, I'm contributing a little to this crate but I don't wish to give too much maintenance burden, sorry if I am...

Currently, this project expects monocypher to be installed in the base system, making it hard to cross compile or compile without installing monocypher first. This article explains a little about the tradeoffs on -sys libraries: https://kornel.ski/rust-sys-crate

Support for building from source could be added by either:

• Adding the monocypher source as a submodule. This would be the best (in my opinion), since it works out of the box, including for cross-compiling. The caveat is that it includes more maintenance burden, since each monocypher-rs would be based on a single upstream version (would need to git pull once in a while), at the same time, upstream updates can break monocypher-rs anyway. There could still be an option to override the source path.
• Adding an option to override the source path, by using MONOCYPHER_SOURCE_PATH env or something like that.

Support for static linking could be accepted by both a crate feature and an environment variable (MONOCYPHER_STATIC).

If you agree with this, I can open a PR (I actually patched and am using with submodule, would need to adapt before opening the PR).

GitHub Actions is fairly easy to setup and doesn't have much of a maintenance burden. I'd be happy to open a PR with a workflow config if it's welcome.