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

Add cargo-deny config #239

Closed
XAMPPRocky opened this issue Apr 30, 2021 · 7 comments · Fixed by #261
Closed

Add cargo-deny config #239

XAMPPRocky opened this issue Apr 30, 2021 · 7 comments · Fixed by #261
Labels
area/build-tools Development tooling. kind/feature New feature or request

Comments

@XAMPPRocky
Copy link
Collaborator

I was reading over the release steps and I noticed there's a step about ensuring dependencies with a specific licence are properly vendored. Embark has already made a tool for checking licences of a dependency. It might be worth automating that step by having a configuration that warns when a dependency with that licence is found in the graph, and then add it to an exception list once it has been archived.

@markmandel
Copy link
Member

🤔 definitely an interesting idea. At the very least, we'll likely need to not allow *GPL licences in the codebase, because they spread. We could bake that into a CI step.

I had a look, but the tool can't do a check to see if the source code is vendored in any way, can it? (that's one of our OSS compliance steps for containers)?

@XAMPPRocky
Copy link
Collaborator Author

I had a look, but the tool can't do a check to see if the source code is vendored in any way, can it? (that's one of our OSS compliance steps for containers)?

Not automatically, but for the vendored licence deps, you could have it always deny or warn until you manually add them to the exception list with the changes to vendor them. That at least gives a trail of who approved what dep, when, and why.

@markmandel
Copy link
Member

If someone added a new MPL licenced dependency (of which we already have one) - Would we get a new notification that there is now a second one above and beyond the first? Or no, since it's already an approved licence type?

I;m assuming we would only get a warning/error on each new licence we haven't previously allowed - not on new versions of an already allowed licence? (if that made sense?)

@XAMPPRocky
Copy link
Collaborator Author

If someone added a new MPL licenced dependency (of which we already have one) - Would we get a new notification that there is now a second one above and beyond the first? Or no, since it's already an approved licence type?

Hmm, yeah there isn't really a nice way to automate this at the moment. But as you said at the very least there are some licences that we don't want, so I can at least add a config covering that and we can go from there. Is there a specific list of licences I can cite or should we just start with the GPL variants?

@markmandel
Copy link
Member

Is there a specific list of licences I can cite or should we just start with the GPL variants?

GPL variants solve both problems. So sounds good to me! 👍🏻

@XAMPPRocky
Copy link
Collaborator Author

Well I guess a better question would be, is copyleft a not allowed in general? For example, are MPL licensed dependencies allowed? Right now we have slog-json which is MPL-2.0.

@markmandel
Copy link
Member

That's an excellent question! I went and double checked.

AGPL is definitely out: https://opensource.google/docs/using/agpl-policy/

From https://opensource.google/docs/thirdparty/licenses/#restricted I would also argue that LGPL and GPL are also out (and the others in this list). They tend to make it harder for external parties anyway, but if we include any of these licences, we can't use this open source product inside Google either.

MPL falls under "reciprocal" licences. They are a bit more tricky, but manageable and okay.
https://opensource.google/docs/thirdparty/licenses/#reciprocal

To SYAC:

The ‘reciprocal’ licenses apply the same permissions and limitations set by the Restricted category of licenses, but with one important exception. The obligation to make source code available to recipients of software that depends on a Reciprocally-licensed library only extends to the contents of the library itself, together with any additions to or modifications of that individual library.

Sound good?

@markmandel markmandel added area/build-tools Development tooling. kind/feature New feature or request labels Jul 8, 2021
markmandel added a commit that referenced this issue Jul 19, 2021
This adds `cargo-deny` to `make test`, which also makes sure it is run
in Cloud Build for continuous integration.

This found a couple of dependencies that need to be updated because of
security advisories. These will be updated in a separate PR.

Closes #239
markmandel added a commit that referenced this issue Jul 19, 2021
When running `cargo deny` locally I found security advisories for both
tokio and prost-types, so bumped them both up to the latest versions in
Cargo.toml, and fixed the issues I found along the way.

Work on #239
XAMPPRocky pushed a commit that referenced this issue Jul 20, 2021
When running `cargo deny` locally I found security advisories for both
tokio and prost-types, so bumped them both up to the latest versions in
Cargo.toml, and fixed the issues I found along the way.

Work on #239
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area/build-tools Development tooling. kind/feature New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants