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

Nuke openssl and git2 #522

Closed
Jake-Shadle opened this issue Jun 15, 2023 · 1 comment · Fixed by #520
Closed

Nuke openssl and git2 #522

Jake-Shadle opened this issue Jun 15, 2023 · 1 comment · Fixed by #520
Labels
enhancement New feature or request

Comments

@Jake-Shadle
Copy link
Member

cargo-deny requires openssl due to its use of git2 for cloning/fetching advisory databases, which is ironic because the original use case we had for cargo-deny was banning openssl from our codebase because it is such a gigantic pain in the ass.

We have 2 options:

  • Use gitoxide to replace git2 and thus get rid of openssl
  • Avoid git altogether and just fetch the advisory databases source tarball. This would work well for the official advisory database on github, but we also have support for custom advisory databases, which complicates that a little bit. Though at the same time I literally don't know if anyone has actually used that feature.

This is somewhat complicated due to the standalone feature which brings in cargo as a dependency, but it has recently begun experimenting with gitoxide as well, though I'm not sure if everything works without it/openssl, but I imagine openssl is still required even if git2 is not used due to the use of curl, but that could be at least a section to tackle separate from git to just completely nuke openssl if one doesn't want it from cargo.

Related: rustsec/rustsec#750

@Jake-Shadle Jake-Shadle added the enhancement New feature or request label Jun 15, 2023
@repi
Copy link
Contributor

repi commented Jun 15, 2023

yes we really should get rid of it! would be wonderful and slim down things.

would be all for gitoxide also, the git usage here is pretty basic right.

but we also have support for custom advisory databases, which complicates that a little bit. Though at the same time I literally don't know if anyone has actually used that feature.

feels like a custom advisory database in different format is probably unlikely used by anyone? one could also support it with an optional feature that could bring in git2 if it is strong need for it by someone and they can't convert to the similar tarball format.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants