You don't need vendoring for this, Cargo.lock already gives you locked-dependencies until you run `cargo update`. There is an ongoing RFC to support having cargo intentionally only use library versions that are least X days old:

https://github.com/rust-lang/rfcs/pull/3923

The repository suddenly contains thousands of files that I need to worry about. With regular locked-dependencies (but non-vendored) like Cargo.lock does, I have them contained in archives with well-known hashes that other people have also looked at.

If I have to manually match the content of the vendor/ folder with the contents of the Cargo.lock referenced source code anyway, I could just use Cargo.lock directly without having to concern myself with the thousands of files in your vendor/ folder.

You are getting distracted by domain names, your Cargo.lock files already cryptographically address the source code. Either make sure all your Cargo.lock files contain no known-bad hashes, or make sure all your Cargo.lock files contain only known-good hashes. Maybe also mirror the .crate files for the absolute worst case scenario of crates.io going offline.

1) This is only relevant for rustup.rs, most Rust source code is coming from crates.io 2) Most projects have a Cargo.lock that contain sha256 checksums of the source code. You can still announce new versions of everything and hope people pull them in through `cargo update`, but you are not going to get anywhere close to "all Rust users".

crates.io _is_ the source code repository (: It's explicitly the source of truth that cargo-crev and cargo-vet reviews are based on, linking it to a git repository first is not a substitute for reading the source code.

This is "only" used for loans and renting, the German government is never going to query the score this company has assigned you. Social services are never impacted.

Equifax on the other hand claims:

> Social Services - When government agencies can't verify your information, you may have to wait longer to start receiving benefits.

The German government probably actually knows who all of its citizens are.

You don't think non-consensually revealing somebody's identity is a problem?

Resorting to DDoS is not pretty, but "why is my violent behavior met with violence" is a little oblivious and reversal of victim and perpetrator roles.

> You don't think non-consensually revealing somebody's identity is a problem?

I do think it’s a problem. You are the only one excusing bad behavior here.

If it's information that's medium-difficult to get, and the only people that would use the information to cause harm can easily put in more effort than that, then I don't think it's "violence" to post that information.

I stopped programming in python about 8-9 years ago because the tooling was so bad.

Step 1: discontinue the public repository, step 2: sell access to your GPL codebase.

The GPL (and even the AGPL) doesn't require you to make your modified source code publicly available (Debian explicitly considers licenses with this requirement non-free). The GPL only states you need to provide your customers with source code.

Sure, but it also allows your customers to modify the source code you provided, and distribute/sell it. With MIT they can simply relicence it and sell binary-only versions. The open-ness stops at that point.

I think this was more about "please choose _any_ license" because of the problem outlined here:

https://opensource.stackexchange.com/questions/1150/is-my-co...