Draft RustSec advisory

[ijackson]

Hi. Someone I know was recently surprised to discover some things cargo-husky had done on their system. On reflection, I concluded that the behaviour, while intentional, is something that a user who builds a depending package ought to be told about, via the RustSec advisory database.

So I have made a draft of such an advisory:
https://github.com/ijackson/rustsec-advisory-db/blob/cargo-husky/crates/cargo-husky/RUSTSEC-0000-0000.md
I haven't submitted it to RustSec yet because I wanted to give you a heads-up, and the opportunity to review my draft. Please let me know your thoughts.

I appreciate that this is rather a difficult situation. Thanks for your attention.

[rhysd]

Thank you, that's a really good point. I think you don't need to wait for my reaction. Please feel free to submit it.

Since cargo-husky is based on a bad hack of build script, something like this can happen. I didn't confirm, but I think looking at CARGO_PRIMARY_PACKAGE environment variable would be able to prevent this issue. I will try it. Meanwhile, the security advisory is effective to let users know the risk.

[ijackson]

Thanks. I wonder whether we are talking at cross purposes. You have tagged this ticket as "bug" but I don't think I am reporting any behaviour which is contrary to the intent of cargo-husky.

Perhaps an example scenario will be helpful:

Suppose Alice is working on some project ("outback" say) which uses some crate "wombat". She finds what appears to be a missing feature in "wombat". So she clones the git repo for wombat, and as a first thing runs "cargo test" (as one does immediately after clone, to check if the tests pass before one starts work).

If the crate "wombat" followed the recommendation in the cargo-husky readme, with an entry for cargo-husky in dev-dependencies, Alice's git clone of wombat will now have had the cargo-husky hooks added.

I think Alice is likely to be surprised by this. I think she ought to have been warned somehow. With my proposed advisory, Alice's "cargo audit" of "outback" would have alerted her to the presence of cargo-husky. She could then take whatever steps she felt necessary.

I don't think there is any change that could be made to cargo-husky that would (a) avoid this situation and also (b) have cargo-husky still perform its function by default.

(I am assuming, without checking, that Alice won't have already experienced cargo-husky's edits to her git hooks when having built her own project "outback", which depends on "wombat", which dev-depends on cargo-husky. If currently Alice would experience that git hook editing just from working on "outback", your CARGO_PRIMARY_PACKAGE idea could prevent that. But I don't see how it can prevent Alice's experiencing the git hook editing when she picks up "wombat".)