3 ms·

> set -e > echo "Downloading piku-bootstrap here." > curl -s https://raw.githubusercontent.com/piku/piku-bootstrap/master/piku->bootstrap https://raw.githubus

• quectophoton 2y ago
  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.
• 1oooqooq 2y ago
  the script is irrelevant. 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.
  • skeledrew 2y ago
    It's a convenience and risk assessment matter IMO. Looking at the repo I see stars in the 1000s, issues are well addressed, and of course the source is available. Lots of persons have likely gone through the code already and no flags were raised, so it's pretty low risk to use that one-liner. I'll definitely use it, as have others, as I just want to get setup and move on with minimal effort.