Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Missing Cargo.lock #61

Open
steinerkelvin opened this issue Dec 6, 2023 · 4 comments
Open

Missing Cargo.lock #61

steinerkelvin opened this issue Dec 6, 2023 · 4 comments

Comments

@steinerkelvin
Copy link

Is there a specific reason for this repo to not have a Cargo.lock?

I need to build this package with Nix and the Cargo.lock is required. It wouldn't make sense to generate this during build, in this case.

@tcharding
Copy link
Member

Rust library crates do not typically commit their lock files. I went looking for a citation for you and stumbled across this

https://blog.rust-lang.org/2023/08/29/committing-lockfiles.html

@steinerkelvin
Copy link
Author

Hum, I didn't know that. TIL.

I solved my problem another way (it wasn't even related to this package lol), so I don't have a demand for it anymore but I guess it could be interesting to add the Cargo.lock with the corresponding adjustments on CI.

@axelpale
Copy link

Wouldn't the missing Cargo.lock make the package susceptible to an attack down in the dependency tree? For example, let's assume zeroize, a dependency of rust-bip39, becomes tampered in a patch version increment. If rust-bip39 does not lock the zeroize version, then new builds that depend on rust-bip39 will install the version that includes the malicious patch.

Of course we cannot know for sure if the patch actually solves a threat instead of introducing a new one, but with a lock file the maintainers are at least let to do their due diligence before upgrading to the patch. Without a lock file things can turn bad without anyone's notice.

To quote the citation above: "there isn't a universal answer to these situations, we felt it was best to leave the choice to developers"

Therefore having a lock file feels more safe. We are talking about a library that deals with bitcoin wallet private keys, after all.

I am new to Rust with extensive JS library background, so my knowledge might fail on how version ranges in Cargo.toml behave. Nevertheless the threat described above is very real in JavaScript domain where lock files are strongly recommended.

@tcharding
Copy link
Member

That would imply that the rust-bip39 maintainers reviewed and signed off on every line of code in every dependency. I don't believe they have nor is it reasonable to expect they will (except if non of the optional dependencies are used since that leaves only bitcoin_hashes which is loosely from the same people). It would be awesome if we all did these kind of reviews, and we over in rust-bitcoin have tried to push cargo crev for just that, but it doesn't seem to be getting much traction.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants