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

Can't issue clarification for unpublished workspace crate retrieved via git #453

Closed
jblachly opened this issue Sep 4, 2022 · 4 comments
Closed
Labels
bug Something isn't working

Comments

@jblachly
Copy link

jblachly commented Sep 4, 2022

Describe the bug
Cargo deny cannot locate files by path in the license-files.path section of [[licenses.clarify]] for crates retrieved via "git" (instead of a registry) which exist within a workspace

As an example, we will use the citeproc-rs library which is unpublished in a registry, but available here: https://github.com/zotero/citeproc-rs/

To Reproduce

Use this Cargo.toml:

[package]
name = "testdeny"
version = "0.1.0"
edition = "2021"
publish = false

[dependencies]
citeproc = { git = "https://github.com/zotero/citeproc-rs" }
citeproc-db = {git = "https://github.com/zotero/citeproc-rs" }

Use this deny.toml:

[licenses]
default = "warn"
allow-osi-fsf-free = "either"
allow = [
  "MPL-2.0"
]
copyleft = "deny"

[licenses.private]
ignore = true

[[licenses.clarify]]
name = "citeproc-db"
expression = "MPL-2.0"
license-files = [
    { path = "src/cite.rs", hash = 0x00 }
]

run cargo deny check licenses

(note that I also tested path = "crates/db/src/cite.rs" which also fails as below)

Expected behavior

I expect citeproc-db to report that it's found the license file , although the hash is wrong.

Instead, it reports that it's unable to locate the file:

   ┌─ /Users/james/src/testdeny/deny.toml:16:14
   │
16 │     { path = "crates/db/src/cite.rs", hash = 0x00 }
   │              ----------------------- unable to locate specified license file
   │

Device:
cargo deny version 0.12.2

Additional Context:

As a side note, I couldn't find a "license" file by path in a local dependency that was specified by path, either, and assume it's related to the same bug (or my same mistake)

@jblachly jblachly added the bug Something isn't working label Sep 4, 2022
@Jake-Shadle
Copy link
Member

This could be fixed, but I am disinclined to do that because what you attempting to do is not a good idea. You are trying to use a source file for the license, so not only is it not an actual license file, but rather just has the license header, and would mean any source changes, even those completely unrelated to the license, would need to be reflected in the changed hash in the deny config.

I'd really recommend doing what every open source project does and putting your license file(s) in the root directory of your crate and either point to it with license-file, or even better, specifying license = "MPL-2.0. If you'd rather not do those changes, like I said, this "bug" can be fixed, but it'd be very low priority, though, PRs welcome.

@jblachly
Copy link
Author

jblachly commented Sep 5, 2022

Hi Jake, thanks for your quick reply!

I'd really recommend doing what every open source project does and putting your license file(s) in the root directory of your crate

Unfortunately, the citeproc-rs packages are not mine. I've made a PR to them to fix another problem but they haven't been responsive. My next step is probably to vendor the dependencies in which case of course I can put a license file as you suggest.

As it relates to bugs, though, there are actually at least two (and perhaps the second is more significant; if you want me to add a second issue, please LMK):

  1. The original issue is a bona fide bug in that path can't find ANY file in git repositories with multiple crates in workspaces. See https://github.com/jblachly/citeproc-rs/tree/deny_bugcheck , a branch in which I added a license file called "legal.txt" in the crate root of citeproc-db.

citeproc-db = { git = "https://github.com/jblachly/citeproc-rs", branch = "deny_bugcheck" }

16 │     { path = "legal.txt", hash = 0x00 }
   │              ----------- unable to locate specified license file
16 │     { path = "crates/db/legal.txt", hash = 0x00 }
   │              --------------------- unable to locate specified license file
  1. maybe the more significant IMO In the citeproc-rs example we are using, the authors HAVE placed a file, LICENSE.md in the root of the git repository, [1] which is a cargo workspace. None of the actual crates (citeproc, citeproc-db, citeproc-io, etc.) have a distinct license file on their own; all are licensed under the same file in the git repository root. However cargo deny applies the found license only to the citeproc crate. Ideally (IMO), it should either apply it to ALL of them, or NONE of them.

[1] https://github.com/zotero/citeproc-rs/blob/master/LICENSE.md

@Jake-Shadle
Copy link
Member

Ahh, apologies, I thought I saw your profile in the contributors list but maybe I just imagined that.

  1. This is because, currently, only files that have license/LICENSE in their filename are actually considered licenses, since, again, this covers the vast majority of open source crates, but I agree it is a minor bug since there are obviously exceptions to this general rule.
  2. Cargo only packages files in the root of the crate, cargo-deny follows this rule when searching for licenses as, unless there is a script that the maintainers run before publishing to copy those license files to each crate they are publishing, those files will not be present in the published crate.

This issue would be mitigated by #390, as in this particular case where a license does exist, but it's just improperly located but still available via git, it can by dynamically retrieved and checked versus needing source changes, though source changes are ultimately the best option since it improves things for everyone.

@Jake-Shadle
Copy link
Member

I just realized this was resolved in #533, the clarification can provide any path it wishes as long as it is contained in the package source.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants