Is there a way to tell cargo-semver-checks to use the system certificate store?

[alilleybrinker]

I am trying to run cargo-semver-checks on a corporate network which uses network security software that substitutes certificates for requests to external sites. The root certificates for these substituted certs are in the system certificate store, but it looks like cargo-semver-checks (as many tools in the Rust ecosystem do) bundles its own certificates.

Is there a way to tell cargo-semver-checks to use the system certificate store?

If not, I'd be happy to help add that. I've done the same before for cargo-release (see this issue: crate-ci/cargo-release#787).

[alilleybrinker]

Aha, it looks like you use tame-index, same as cargo-release does, so the solution here could be the same as what I did there: add the native-certs feature for tame-index and then expose a CLI option to use the webpki certs, the system certs, or both.

[obi1kenobi]

Hey, thanks for opening the discussion and also opening a PR. This is a bit of a tricky situation, so I'm sorry and please bear with me as I explain.

For structural reasons, cargo-semver-checks as a project operates on the very limit of feasibility from a maintenance perspective. It needs to work for essentially everyone on crates.io, for all their feature combinations, on all their supported platforms, with all the cursed code anyone could possibly come up with.

The risk isn't hypothetical: several prior SemVer linter projects got abandoned over not being maintainable enough to bear the weight of the ecosystem being on them. I'm stretched paper-thin here already, and I don't want cargo-semver-checks to be another casualty. So I have to be extremely cautious about any source of additional maintenance burden.

The new feature here is only of interest in a corporate environment. It also adds extra complexity, and more ways for things to fail in difficult-to-debug ways. One of two things is true:

• Option A: cargo-semver-checks creates substantial value for the company, more than enough to offset the negatives.
• Option B: cargo-semver-checks creates negligible value for the company, not enough to offset the negatives.

If Option B is true, then we shouldn't add this feature — it's a pure risk to the project and it isn't worth it. If Option A is true, then I'd like to get the company onboard as an official sponsor of the functionality: logo in the repo, social media thanks, etc. If you think that's worth it, I'd love to work with you to convince the company to fund the project on a material and ongoing basis.

I really hope we can make that work!

In the meantime, I'm unfortunately not able to accept the PR. The code there is "free as in puppy". I also wouldn't be upset if you'd like to maintain a fork with this functionality for your company's use, though I'd be lying if I said that wouldn't feel disappointing and demotivating. Definitely not my preferred outcome!

So keeping my fingers crossed that we can get a win-win here! 🤞