WIP: add cargo-deny job

[TriplEight]

Resolves #922

• temporarily runs every commit but later will change it to run before the merge and nightly
• fails when encounters
  • unlicensed workspace members
  • vulnerabilities from advisories
  • uncertain and unlicensed deps
  • parity-util-mem <0.6
• warns about everything else:
  • unknown git sources
  • duplicate dependencies
  • unmaintained/yanked crates

[TriplEight]

An example of the check: https://gitlab.parity.io/parity/polkadot/-/jobs/427639

[kirushik]

It's good that the new check indicates our own unlicensed dependencies.
At the same time, I'm not sure I understand, who and why did pick this rather questionable licensing approach. Say, why wouldn't we want MPL-licensed dependecied in our GPL-licensed client?

Also: you could've at least clarified ring's license in the config.

[TriplEight]

Example of job now: https://gitlab.parity.io/parity/polkadot/-/jobs/429231

[TriplEight]

Also: you could've at least clarified ring's license in the config.

done, what else needs to be done in this PR? @gnunicorn ?

[gnunicorn]

With #922 already resolved, what we are trying to accomplish here exactly? I am rather hesitant to add more CI tasks unless they are strictly necessary, as our CI is already under a lot of load.

Is the plan to have that run with every PR? Or as a nightly job? If the later I think this is fine to do (aside from that it currently fails, so merging is blocked ;) ) – but we should probably automatically open tickets when we find this one failing as well.

//cc @s3krit

[TriplEight]

@gnunicorn

Is the plan to have that run with every PR? Or as a nightly job?

Of course it doesn't make sense to run it every commit. Ideally, I'd want it before merges (but currently we can't do that). I can suggest running it either on master (so after merges and nightly) or just nightly, but the latter would only make sense if it would automatically create issues.

it currently fails

I'm not sure if we've decided something on what to do with those 17 internal licensing errors.

[kirushik]

@gnunicorn IMO, merging a PR (especially a third-party one) with some questionable licensing should be avoided, even if at cost of some additional CI load (this task shouldn't add much anyway).

1. Merging a PR with potentially questionable licensing might be viral, and can taint the licensing state of the whole codebase on master at that point. No simple PR would be enough to fix that, we would need some revision history surgery on master to undo the damage (and it's still not 100% certain that it will fix all the potential issues). Think of merging a GPL-licensed dependency into a MIT-licensed library — isn't all your code now implicitly GPL-licensed forever? Tough question, let's not find out.

2. Woudn't it be much easier to resolve the issue with an offending dependency right in the PR where it was added, while everyone's context is still fresh? Again, for the case of third-party contributor it would require someone else than the official author to reengineer our freshly-merged code — not ideal.

All this of course doesn't apply to checking advisories with cargo-deny, only to its license-checking capabilities.

[gavofyork]

@s3krit closing due to being stale. reopen if needed.