Rust-Written Coreutils Replacement uutils 0.0.19 Released

[lowflyer]

cargo-deny can handle dependancy licences, it's a great and lovely tool

cargo-deny can be used to deny any non-conforming license, ban certain crates and check advisories for CVEs.

As good as that tool is, cargo-deny does not solve the problem. It may be of help, but it's only a first step. Can you blindly trust the licenses advertised in a crate? Or in any other piece of software that is?

The fact that such a tool already exists confirms there is a real problem out there.

You actually have to check whether the code is correctly licensed. All of it. The whole dependency chain! You will not impress anyone in a court case with an answer like "We used cargo-deny..."

[lowflyer]

I don't see that, crates I use never pull in that many dependencies.

Good if you are careful with the dependencies. But what about the crate authors? Just wait. Given enough time, there will be crates that boldly go where no human has been before.

The problem is that crates can pull in other crates. The whole thing is inspired by how Javascript does it. Since most web developers are completely ignorant on licensing issues, it created a whole self sustaining "eco system" over time. It works as long as you don't ask too much about licenses.

There is already this problem. Not exactly the same, but similar.

[NobodyXu]

As good as that tool is, cargo-deny does not solve the problem. It may be of help, but it's only a first step. Can you blindly trust the licenses advertised in a crate? Or in any other piece of software that is?

It would already solve a lot of problem, since according to my own experience most people do put up the same license as advertised on crates.io
Also, cargo-publish usually includes everything in the crate recursively onto crates.io unless explicitly opt-out, so for that case, we can also check for LICENSE or if dual-licensed under apache and mit, we can check for LICENSE-APACHE and LICENSE-MIT.

If they do not have license there, we can reject it.

The fact that such a tool already exists confirms there is a real problem out there.

This is always a problem unless you don't use any dependency at all.
Even the glibc header and libstdc++ header itself has to separately license to since they are statically linked into final binary, making it essentially "redistribution".

Statically linked with glibc thus is not only technically hard due to design flaw, but also creates license issues due to use of GPL.

You actually have to check whether the code is correctly licensed. All of it. The whole dependency chain! You will not impress anyone in a court case with an answer like "We used cargo-deny..."

Sure, but in general I found this to be relatively ok.
Most well-maintained crates I use advertised their license correctly and usually they just use apache/mit or both.

[bug77]

The person I responded to was defending the use of 80+ dependencies by saying that unit tests solved the inherent risks. I was refuting that specific argument.

Between unit, integration, fuzz and even mutation tests, you can guarantee your code still works when dependencies change. It's hard to do it properly, it takes a while. But projects that really need that kind of guarantees, will have the budget for it.

[NobodyXu]

Good if you are careful with the dependencies. But what about the crate authors? Just wait. Given enough time, there will be crates that boldly go where no human has been before.

Well, you have the choice to not pull in arbitrary dependencies.
cargo gives you power to easily pull in other crates, but it does not mandate you have to pull in other crates.

Not to mention that there's a lot of good crates out there that have opt-in features to control dependencies (e.g. http client reqwest) and many crates are maintained by organization like rust-lang, rust-random, hyperium, taiki-e, dtolnay that is trust-worthy.

The problem is that crates can pull in other crates. The whole thing is inspired by how Javascript does it. Since most web developers are completely ignorant on licensing issues, it created a whole self sustaining "eco system" over time. It works as long as you don't ask too much about licenses.

Yes, but there are authors/organisations/crates that are trust-worthy and won't pull in any incompatible license, which means MIT/APACHE only.

There is already this problem. Not exactly the same, but similar.

That is a completely different problem from dependency resolution, rather about semantics of Rust no_std.

[Quackdoc]

You actually have to check whether the code is correctly licensed. All of it. The whole dependency chain! You will not impress anyone in a court case with an answer like "We used cargo-deny..."

go tell that to ffmpeg based applications

[lowflyer]

go tell that to ffmpeg based applications

I am currently working on an FFmpeg based application. That's why I bring it up.

[lowflyer]

This is always a problem unless you don't use any dependency at all.

That's exactly the point I'm trying to get across. Someone in this forum mentioned: "code reuse is a good thing". To which I generally agree. But it has limits. One such limit is the chain of dependent licenses.

Sure, but in general I found this to be relatively ok.

"relatively ok" may be good enough for you, but is it good enough for your company's license lawyer?

Well, you have the choice to not pull in arbitrary dependencies.
cargo gives you power to easily pull in other crates, but it does not mandate you have to pull in other crates.

One example: Your project "Adam" pulls in crate "Beta" which you found extremely useful because it has that "mogrify(stuff)" function that is absolutely amazing. But that "Beta" crate depends on crate "solvent" - which is not too much of a problem because it is small - but this one depends on "arbiter", "moab" and "dateconverter". Out of these three, "moab" pulls in some other licensed code,

What is the earliest point in your development process where you see a crate is not acceptable?
What are your options when you later find out that it contains snippets of code that have been leaked from a Taiwanese company?
Can you just deny the "moab" crate? I guess not - since the other crates depend on it.

... there's a lot of good crates out there that have opt-in features to control dependencies
... and many crates are maintained by organization like ... that is trust-worthy.
... there are authors/organisations/crates that are trust-worthy ...

I don't deny that there are many responsible authors out there. But there are also "the other ones". And their code will inevitably end up someday on crates.io. cargo-deny cannot help you with this problem. It can help to block crates only once you know them.

The "revolutionary new thing" with rust is the ease of code re-use thanks to crates. It turns out that it was not so revolutionary. It was already there in web technologies like javascript and python. Projecting from these languages, this will happen to rust: It will improve productivity but it opens a bucket full of worms in other areas, like nested dependencies and their licenses and code quality.

That is a completely different problem from dependency resolution, rather about semantics of Rust no_std.

It is a different problem at the source, but the outcome is exactly the same: You have code in your project that you (the author) did not expect to be in there.

[Quackdoc]

I don't deny that there are many responsible authors out there. But there are also "the other ones". And their code will inevitably end up someday on crates.io. cargo-deny cannot help you with this problem. It can help to block crates only once you know them.

I am currently working on an FFmpeg based application. That's why I bring it up.

cargo-deny recursively checks dependency tree as well as opt in deps. I really don't see how this can be possible without an entire team working on it, checking every bit of code to manually make sure there are no patent infringements, as long as the tree is good that would be fine due diligence.

assuming you really *need* a crate that pulls in an incompatible dep (which you would find out by adding the crate, running cargo-deny before work starts) it's just like anything else, fork it, strip out or make the deps optional, or replace it yourself, that doesn't really change anything. as for the leaks part. this changes literally nothing. just replace the bits once you are aware of it. and if it's too large to replace you are SOL, but that changes literally nothing from C

[NobodyXu]

That's exactly the point I'm trying to get across. Someone in this forum mentioned: "code reuse is a good thing". To which I generally agree. But it has limits. One such limit is the chain of dependent licenses.

of course it is, license will always be a problem.

"relatively ok" may be good enough for you, but is it good enough for your company's license lawyer?

That will depend on what crate you use.

Companies can set whitelist of crates allowed, e.g. only crates from trusted authors with MIT/Apache license.

What is the earliest point in your development process where you see a crate is not acceptable?

If you set whitelist of authors to be trusted to someone who are responsible (with good track records) and then limit license to MIT/Apache, then it can be rejected when adding the dependency.

What are your options when you later find out that it contains snippets of code that have been leaked from a Taiwanese company?
Can you just deny the "moab" crate? I guess not - since the other crates depend on it.

You can certainly deny the crate, by removing the dependencies depended on it, and add it to blacklist.

I don't deny that there are many responsible authors out there. But there are also "the other ones". And their code will inevitably end up someday on crates.io. cargo-deny cannot help you with this problem. It can help to block crates only once you know them.

Why not just use whitelist of authors to be allowed?

Or even whitelist of crates to be trusted, with each new added ones have to go through thorough review on its code and the author?

In case of an emergency, you can write your own moab crate from ground up, and use cargo patch.crates-io feature to replace that crate in question.

The "revolutionary new thing" with rust is the ease of code re-use thanks to crates. It turns out that it was not so revolutionary. It was already there in web technologies like javascript and python. Projecting from these languages, this will happen to rust: It will improve productivity but it opens a bucket full of worms in other areas, like nested dependencies and their licenses and code quality.

It's not that evolutionary, and that's why this is not going to be a big problem.

Corp has experience dealing with this for a long time, using whitelist for authors/crates is the most robust approach.

Having a package manager will always better than without one, having to manually install the dependencies using apt-get or manually download, extract and compile really is just wasting time, where you can allocate these resources to actually review the dependencies.