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

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.

it's the culture it attracts/creates when you start with this.

and while i didn't look at the script for the reason above, i did look at the site and found no high level or architecture designs links.

good luck basing, even your dev, infrastructure on things like this.

I always do a mental `exit 1´ upon encountering `curl | sh´. It's just a good practice.