@silwol I've personally never understood why it's a bad thing to ship Rust applications with vendored sources. Packaging problems solved. No more duplicated effort to repackage everything that the Cargo.lock file and vendoring already maintains.
Well, that's due to the "#Debian way" of doing things with the motivation of getting things right from a specific point of view. The copyright of all packaged components needs to be documented properly (https://www.debian.org/doc/debian-policy/ch-source.html#copyright-debian-copyright), and so-called "convenience copies" (https://www.debian.org/doc/debian-policy/ch-source.html#convenience-copies-of-code) are only allowed under some tight conditions. It's sometimes a tedious procedure, but one can acknowledge that it carried them a long way.
Of course, the Debian security team would not be very happy if they have to fix a vulnerability in one of the central crates. They would find many different bundled versions of the same code (*if* they find them at all), and then a patch would have to be ported for each of these in order to keep the changes minimal to make it possible to reason about them. Porting the patch only once increases clarity a lot.
@silwol The issue is that Debian's system is designed around packaging C software, but this model is completely incompatible and outdated with Rust packaging.
If they really want to make Rust a first class system, then why not use Cargo to their advantage and create their own Crates.io mirror?
Not that they should really need to duplicate that effort. There's nothing wrong with re-vendoring packages with the vulnerabilities. Easy to automatically find in the Cargo.lock file.
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!