In defense of their argument (not their choice of words), the final script is doing a `git clone`, so if they're going to ask the user to copy-paste anyway, the

In defense of their argument (not their choice of words), the final script is doing a `git clone`, so if they're going to ask the user to copy-paste anyway, their copy-paste code could be something like: PUBLIC_KEY_FINGERPRINT='SHA256:KnownPublicKeyFingerprintHere' git clone 'https://github.com/piku/piku-bootstrap' 'piku-bootstrap' && \ cd 'piku-bootstrap' && \ (git verify-commit $(git log -1 --pretty='format:%H' -- README.md) | grep 'Good "git" signature with ED25519 key '"${PUBLIC_KEY_FINGERPRINT}") && \ (git verify-commit 'HEAD' | grep 'Good "git" signature with ED25519 key '"${PUBLIC_KEY_FINGERPRINT}") && \ ./whatever-command-from-this-repo (EDIT: Feel free to clean it up a bit, adding other variables to make it a bit more readable, etc.) From the user's POV it's the same thing: copy from somewhere, paste into terminal, press enter. But now you're trusting two fewer places: - piku.github.io (the deployed version) - github.com/piku/piku.github.io (the source code that supposedly generates the deployed version) I'm not saying to do exactly these steps, and they are not perfect anyway (you're still trusting a `git clone` before even doing any kind of verification), but at least you're not YOLOing[1] without first doing some minimum verification of integrity before something is executed, so you know at least the first installation step has not been tampered with[2][3]. The git repos don't have commit signatures, and the verification doesn't have to use specifically those kind of signatures (could be a minisign public key hosted somewhere), but you get the point. The updates are also a `git pull`, meaning, if the commits were signed, and the installation copy-pasta (or script) included a step that added the author's public key to the allowed signers file (TOFU-style), e.g. with a `curl` to the author's GitHub's keys URL, then `git pull --verify-signatures` could check new commits against the already-known key, and automatically warn about any changes so the user could decide if trust the new key or not. Stuff like that. [1]: Nowadays, saying "install with `curl | sh`, but you can also do install these other ways", is equivalent to saying "verify integrity with `md5sum`, but you can also check this other file if you want to see other hashes"; technically correct, but if the installation instructions already contain questionable defaults, it makes me question what other questionable defaults are in the actual code. [2]: "Has not been tampered with" as in "the last modification of `README.md` and the most recent commit are signed with the same key". Not perfect, but it's not YOLO. [3]: Emphasis on "first installation step". Obviously anything that happens after that simple sanity check would need more scrutiny in case the author tries to run unsigned/unverified code in one of the next steps.