search

breard-r / acmed

ACME (RFC 8555) client daemon
MIT License
171 stars 25 forks source link

Lock the dependencies by committing the Cargo.lock #61

Closed breard-r closed 1 year ago

breard-r commented 2 years ago

Why this issue?

Recently, there has been a lot of supply-chain attacks (1, 2, 3). While the most notorious are part of the JavaScript ecosystem, such an attack is conceivable in the Rust ecosystem.

Because ACMEd does not commit the Cargo.lock file, it is vulnerable to such an attack from one of its dependencies. This issue will be closed when this is solved.

What does committing the Cargo.lock implies?

Locking the dependencies is not a trivial job. It comes with two major sources of work:

  1. create more frequent releases in order to keep up with dependencies improvement
  2. analyze the changes in all dependencies

When will it come to ACMEd?

Currently, ACMEd is still in a development phase and subject to breaking changes. Most of its improvement comes with little to no warning, hence a little chaos.

My current and personal point of view on this matter is that ACMEd should only lock the dependencies once it reaches the first stable version. Therefore, all version 0.x.y will not include the Cargo.lock file, but versions 1.0.0 and later will include it.

Meanwhile

Those who whishes to package ACMEd for their system may want to enforce dependencies lock. While ACMEd is still in development, those people may create and include their own Cargo.lock file. The counterpart of doing so is that you would have to maintain this file yourself, and therefore be responsible for all the subsequent work.

Good news: ACMEd is starting to be quite mature and therefore the first stable version should not be in an eternity. Bad news: before declaring ACMEd stable, I really wish to refactor a few things, which may still take some time, depending on my personal life.

jcgruenhage commented 1 year ago

https://doc.rust-lang.org/cargo/faq.html#why-do-binaries-have-cargolock-in-version-control-but-not-libraries is very clear about recommending that all binaries should check in their Cargo.lock file. The requirement for frequent releases is there already in my opinion, because without them, people aren't going to rebuild acmed. If you assume they will rebuild acmed without a new release, then I'd say it'd also be fair to assume that they'd run cargo update before, to ensure that they get the newest dependencies.

With regards to analyzing all changes in all dependencies: I don't think that is feasible, ever, and even if it was, it's not related to checking in the Cargo.lock file IMO? There's cargo crev for this that works on a Web of Trust basis and operates on positive/neutral/negative assessments for crates, or lists of advisories on problematic crates/crate versions in the RUSTSEC database. IMO, working with cargo audit and the RUSTSEC database is enough here, and if we want to go the extra mile, we can do spot checks which we then document with cargo crev, but checking in the Cargo.lock file should be blocked on those things.