Add wait-for-them

[jayvdb]

https://github.com/shenek/wait-for-them

[jayvdb]

Raised https://github.com/shenek/wait-for-them/issues/53

[NobodyXu]

Not saying that I'm oppose to adding rust crate to this action, it's that with the cargo-binstall fallback, we don't have to add support here manually and maintain it to get the support, so we may not need to add everything here.

I'll let @taiki-e makes the final decision though because I maintain cargo-binstall so have a cognitive bias.

[jayvdb]

I'll comment here once about your rejections of this, jaq, and xh. cargo-binstall is not good enough for my industry, healthcare, and other sectors I have worked in that are highly regulated, such as automotive. binstall uses the signature on the releases page, which can be changed at the same time a maintainer changes the binary. This is effectively useless security theater, that only protects against simplistic supply chain attacks, and only if the project supplies checksum files, which many Rust projects dont provide.

Also binstall uses quickinstall as a fallback. That means for me to use cargo-binstall, I need to get both cargo-binstall and cargo-quickinstall reviewed & approved - and both are much more complicated than install-action from a "trust" perspective, and both provide less guarantees than install-action. In short, they are not going to be approved.

So, cargo-binstall is not a fallback for me, and many other projects that have strict controls in place. cargo-binstall installs SOUP which cant be justified in Github workflows.

[NobodyXu]

cargo-binstall is not good enough for my industry, healthcare, and other sectors I have worked in that are highly regulated, such as automotive. binstall uses the signature on the releases page, which can be changed at the same time a maintainer changes the binary. This is effectively useless security theater, that only protects against simplistic supply chain attacks, and only if the project supplies checksum files, which many Rust projects dont provide.

Yeah that's indeed a problem for healthcare industry, though do note that cargo-binstall supports having a dedicated public key for every release, with the public key stored in the https://crates.io by putting it in Cargo.toml thus immutable and the private key is only used in the GHA CI and erased once the release is done.

https://github.com/cargo-bins/cargo-binstall/blob/main/SIGNING.md

Unfortunately cargo-binstall is used on client so we can't cache the hash sum like taiki-e/install-action, which like you say, is the main advantage of this action.

Though just TBF if someone takes over the GitHub account of any maintainer of these popular crates and obtain ability to publish it (maybe through GHA to auto-publish release to crates.io), or someone malicious becomes the maintainer, even taiki-e/install-action can't prevent it.

Maybe cargo-binstall could use the hashsum stores in taiki-e/install-action to verify the release?

Also binstall uses quickinstall as a fallback. That means for me to use cargo-binstall, I need to get both cargo-binstall and cargo-quickinstall reviewed & approved - and both are much more complicated than install-action from a "trust" perspective, and both provide less guarantees than install-action. In short, they are not going to be approved.

That can be disabled, though only through commandline parameters --disable-strategies quickinstall, though it does make it harder to use for your use case.

So, cargo-binstall is not a fallback for me, and many other projects that have strict controls in place. cargo-binstall installs SOUP which cant be justified in Github workflows.

That's true, cargo-binstall is designed to be a drop in replacement of cargo-install, though TBF, IIRC taiki-e/install-action previously fallback to cargo-install if it is not directly supported.

[NobodyXu]

BTW cargo-binstall also has plan to support more signature schemes https://github.com/cargo-bins/cargo-binstall/issues/1#issuecomment-1740221953