4 ms·

Ultimately, the only insecure thing about curl-to-bash is if you don't trust the server — the server in this case being Github. I think few people or companies

Ultimately, the only insecure thing about curl-to-bash is if you don't trust the server — the server in this case being Github. I think few people or companies include Github-being-malicious in their threat model; if Github was malicious, any build artifacts produced by even cloning from Github would be potentially suspect, since Github could fairly easily detect automated build agents and serve them different content (especially if the build agents were integrated with Github Actions, which is fairly common these days — or even if they were just using Github webhooks). If you do continuous delivery, or even if you just do continuous integration and then don't have a human decompile and audit every line of the build artifacts after they're created, you de facto trust your repo host; for most people that means Github.

rjzzleep 5y ago
I'm not going to go into the curl|sh debate, but there is actually something wrong about what you described. Trusting the server doesn't apply to Github at all. Github is technically like a bazaar or mall. It's wrong to assume that if you trust a store on the bazaar you then trust ALL stores on the bazaar. You personally may, but then I strongly question your sense of security. Sure, you trust that Github doesn't add malicious stuff when cloning, but each repo on Github is kinda it's own "server" to fit into your analogy.
- reissbaker 5y ago
  The link being used in the curl-to-bash example from the original discussion is a direct link to content in the repo itself — so if you trust that repo server for its content, it doesn't matter whether you curl-to-bash or not. If that Github server is malicious you're in trouble. FWIW though, if Github servers have a vuln that allows attackers to modify repo content being served on a per-request basis, it's pretty likely that many repos (or even all repos) would be vulnerable, not just one. From a security standpoint I'd consider Github repo servers to be a tier of servers that you do or don't trust; saying that you trust one "server" within the tier but don't trust another doesn't make a lot of sense, especially since you don't actually know the topology behind their DNS and the "servers" are virtualized, colocated, and parts of them are ephemeral. What exactly are you trusting? Other than "I sent a request to Github and it gave me a response" there's not much you can say for certain — the request could've been routed to any number of repo servers, that may be hosting dozens of other repos on them as well. The server that responds today is likely a different virtualized server than the one that responds tomorrow, just attached to the same filesystem. But even if that weren't true, curl-to-bash in this example seems ultimately fine for most people. If I were doing devops work that required Kubescape for an org, I would definitely package it into a deb (or whatever package format the org used internally) and install it that way rather than curl-to-bash. But that's not because of security gains from a deb vs a script, that's because I'd want to lock it to a stable version rather than always installing latest, and I wouldn't want to tie availability of Kubescape to Github repo servers being up (they do go down sometimes). But for getting started playing around with it, curl-to-bash is low friction, can easily support multiple OSes as compared to debs, and seems generally fine as it is used here.
- mishafb 5y ago
  This is equivalent to running a Makefile or a pre-built executable as your user which you're bound to do anyway
  - anotherhue 5y ago
    It is unusual for an executable to install itself, and good Makefile practices has a separate install stage than a build stage. No doubt, these conventions can be and are ignored, but they are good conventions.
anotherhue 5y ago
OP. Of course if there's trusted parties along the way it's safe enough. But it is not durable to that trust being broken. e.g. if the user has learned to do this, and ends up through typo squatting on a malevolent fork of their code. If it's okay on GH, we train the user to think it's okay on less secure sites.

rjzzleep 5y ago

I'm not going to go into the curl|sh debate, but there is actually something wrong about what you described. Trusting the server doesn't apply to Github at all. Github is technically like a bazaar or mall. It's wrong to assume that if you trust a store on the bazaar you then trust ALL stores on the bazaar. You personally may, but then I strongly question your sense of security. Sure, you trust that Github doesn't add malicious stuff when cloning, but each repo on Github is kinda it's own "server" to fit into your analogy.

reissbaker 5y ago
The link being used in the curl-to-bash example from the original discussion is a direct link to content in the repo itself — so if you trust that repo server for its content, it doesn't matter whether you curl-to-bash or not. If that Github server is malicious you're in trouble. FWIW though, if Github servers have a vuln that allows attackers to modify repo content being served on a per-request basis, it's pretty likely that many repos (or even all repos) would be vulnerable, not just one. From a security standpoint I'd consider Github repo servers to be a tier of servers that you do or don't trust; saying that you trust one "server" within the tier but don't trust another doesn't make a lot of sense, especially since you don't actually know the topology behind their DNS and the "servers" are virtualized, colocated, and parts of them are ephemeral. What exactly are you trusting? Other than "I sent a request to Github and it gave me a response" there's not much you can say for certain — the request could've been routed to any number of repo servers, that may be hosting dozens of other repos on them as well. The server that responds today is likely a different virtualized server than the one that responds tomorrow, just attached to the same filesystem. But even if that weren't true, curl-to-bash in this example seems ultimately fine for most people. If I were doing devops work that required Kubescape for an org, I would definitely package it into a deb (or whatever package format the org used internally) and install it that way rather than curl-to-bash. But that's not because of security gains from a deb vs a script, that's because I'd want to lock it to a stable version rather than always installing latest, and I wouldn't want to tie availability of Kubescape to Github repo servers being up (they do go down sometimes). But for getting started playing around with it, curl-to-bash is low friction, can easily support multiple OSes as compared to debs, and seems generally fine as it is used here.
mishafb 5y ago
This is equivalent to running a Makefile or a pre-built executable as your user which you're bound to do anyway
- anotherhue 5y ago
  It is unusual for an executable to install itself, and good Makefile practices has a separate install stage than a build stage. No doubt, these conventions can be and are ignored, but they are good conventions.

anotherhue 5y ago

OP. Of course if there's trusted parties along the way it's safe enough. But it is not durable to that trust being broken. e.g. if the user has learned to do this, and ends up through typo squatting on a malevolent fork of their code. If it's okay on GH, we train the user to think it's okay on less secure sites.