Support host's local certificate store

[hpenne]

cargo-vet does not seem to support the host machine's local certificate store when downloading files. This makes it impossible to download from servers on the company's local network. These are typically using certificates generated by the organization itself, while rustls only seems to use Mozilla's approved trust anchors by default.

It seems that this can be remedied by using something like rustls-native-certs.

There are other important security advantages in doing this, but also some potential drawbacks (see https://crates.io/crates/rustls-native-certs under "Should I use this or webpki-roots?").

Would you consider adding support for this? It seems that all that is required is to change the cargo.toml file's entry for reqwest to specify the "rustls-tls-native-roots" feature instead of "rustls-tls". If this is not acceptable as a default, then it could be supported as an optional feature in cargo-vet so that users that want support for native certs can enable the feature when installing through something like "cargo install -F native-certs cargo-vet".

If you don't have time to do this yourselves then would you welcome a Pull Request containing these changes?

[hpenne]

It seems that there is an additional challenge in downloading from company servers, in that cargo-vet does not use the configuration in your local .cargo directory and always downloads crate data from crates.io, even when .cargo is configured to use a local mirror. This will take more work to fix.

[hpenne]

I made myself a fork of cargo-vet and have worked on adding support for registry redirect setups in .cargo/config.toml.
This allows cargo-vet to run against company internal crate mirrors. It also supports certificate roots/TAs configured locally on your host by your IT departement.
My initital tests look good, and the changes are mostly new code and integrated easily with your existing code.
What remains is some more testing and adding some more error reporting for diagnostic purposes if the user sets up the config.toml incorrectly, etc.
@bholley Would you consider a pull request when this is all done?

[mystor]

In general we want all audits in cargo-vet to operate against the real crates.io, rather than against a mirror, which is the primary reason why we don't support things like registry redirects. If someone publishes an audit for a crate, that audit is for the crate as it exists on crates.io. Given that audit sharing is a focus of cargo-vet, we don't want to encourage folks to publish audits which operate on a different version of the registry.

Because of this, we generally want to make sure that the code you are auditing & acting upon comes from the real crates.io, rather than your replacement, so that we can be sure that you are reviewing the correct code. This avoids potential problems like someone vendoring & modifying a crate, and using a crates.io redirect to direct to the vendored copy, then auditing the modified version, rather than the version on crates.io.

[hpenne]

@mystor This is a valid argument. It all boils down to how much trust you are willing to put in the user to do things the right way. On the other hand, I suspect that most users who need the ability to redirect to a mirror will have a mirror that contains exact copies of the crates on crates.io, in which case the use of a mirror is perhaps not a real problem.

The users who need redirect support are users that are likely to operate in an environment that is not directly connected to the internet. These users are likely to be particularly interested in supply chain security, and could be some of your strongest supporters. If you look at it from that angle then there might be some long term benefits in supporting them. I'm not claiming that you are wrong, just that there might be different perspectives on this.

Anyway, this is not a problem for my use. It is fairly simple for me to maintain a fork of your code for my own use, but my changes will not benefit anyone else that way.