curl + exec install is bad practice

[fmoessbauer]

The README.md proposes to install the witness tool using the bash + curl one-liner:

bash <(curl -s https://raw.githubusercontent.com/in-toto/witness/main/install-witness.sh)

This is really bad practice in general, but for a tool that focuses on supply-chain security this should not be the proposed way to install it. Not even a checksum of this script is provided (for the initial entry point - the install-witness.sh script).

While this might sound like a nit-pick, it does not put the whole in-toto project into a good light if these fundamental issues appear as one of the first things people see.

I propose to fully drop this script from the project.

[jkjell]

Definitely agree with this. I found what looks like a good set of alternatives from the Sigstore cosign install docs: https://docs.sigstore.dev/system_config/installation/. It'll take a bit to add all of these and communicate the deprecation of the current method. Let me know if there's any other install methods you'd like to see (or if you have concerns about any of the cosign install methods).

[shibumi]

Bootstrapping trust is a hard problem. In my opinion, a common root of trust, like the sigstore root, can help with that.
See also: https://docs.sigstore.dev/system_config/installation/#verifying-cosign-releases

Not even a checksum of this script is provided (for the initial entry point - the install-witness.sh script).

The install script itself handles checksum verification, but it is negligible due to the missing trust bootstrap.

To be honest, I think the documentation in https://docs.sigstore.dev/system_config/installation/#verifying-cosign-releases not perfect either.. too many manual steps.

I worked on BLOB support in sget a while ago: sigstore/cosign#1190

But it never got merged, because of bigger plans (support for purls, etc)

[fmoessbauer]

Bootstrapping trust is a hard problem.

Yes, but IMHO the solution does not need to be perfect either. How about simply referencing the github releases page. There we already have the prebuilt binaries + checksums. Ideally the binaries are reproducible, so an interested user can reproduce them.

The intention of this issue was just to point out the bash<(curl ...) antipattern.

[matglas]

We could sign the install script too. Allow that to be checked against cosign verify-blob and its signature. That is easy to document I believe and still allows the script to be used to support multiple environments. From there it could be possible that if we find a cosign command also the downloaded binaries are validated with their sig from the release.

[adityasaky]

Thinking about it, signing the install script would mean the user would have to verify the signature on that before executing it. Even if you could make it a convenient one liner, there's an automatic expectation the user has cosign installed (with that bootstrapped securely). Plus, if they're copying the one liner that includes the signing identity / OIDC issuer etc., IDK if there's value in signing the script -> if someone can modify the script stored on the github repo, they can likely modify the README or wherever to include any verification parameters that the user isn't paying attention to in a long one liner.

I wonder if it's really just best to update the instructions to get the user to fetch the release binaries themselves + documentation about verifying signatures / attestations generated during a release. This is still susceptible to the fact that anyone who can attach a bad release can likely update these docs, but at least it's less automatic-bunch-of-text-scrolling-on-my-screen? It may get us going until we have something like PEP-480? Also, maybe pointers to homebrew etc., if they don't already exist.

[matglas]

@adityasaky I think your suggestion sums up the whole of this thread and a good description of installing based on release page would be best. Do you agree @adityasaky?

A small suggestion from me: @fmoessbauer as the author of this issue would you be open/have time for a proposal that would describe what @adityasaky mentioned?