5 ms·

I didn't mean that this is going to happen. I wanted to give an example of a potential threat. My idea was to show one of many problems with centralization and

• Kalium 8y ago
  There's definitely a need for a better system. Some would argue that we have package managers specifically to help solve this problem. Yet, for many developers who just want a "good enough" install system without thinking or working at it much, curl-and-exec gets the job done. That so many people aren't thinking about security at all is a sad comment on the state of software engineering. But perhaps inevitable, given our cultural history of favoring freedom over security.
• morley 8y ago
  > I wanted to give an example of a potential threat. I really don't like this line of thinking. It's the same one used by news organizations to plump up their stories, or by politicians to make an improbable threat seem more real. In both of those cases, I think the long-term effect is to cause the public to think that very rare events are a lot more common. The result is not a culture of wariness but a culture of fear. I'd much rather people present "worst-case potential threats" instead as "likely potential threats."
  • sanbor 8y ago
    In security many things are "potential" threats. Just being unlikely doesn't mean that the threat doesn't exists. For example, a guy found a potential threat in rails[1], and rails developers dismissed his findings as unlikely exploitable. Then the guy go and hacked GitHub to prove that the issue was real[2][3] and that even the best rails developers were vulnerable. [1] https://github.com/rails/rails/issues/5228 https://github.com/rails/rails/issues/5228 [2] https://github.com/rails/rails/commit/b83965785db1eec019edf1fc272b1aa393e6dc57 https://github.com/rails/rails/commit/b83965785db1eec019edf1... [3] https://arstechnica.com/information-technology/2012/03/hacker-commandeers-github-to-prove-vuln-in-ruby/ https://arstechnica.com/information-technology/2012/03/hacke...
  • Kalium 8y ago
    OK. Let's not talk about potential threats. That's the language of fear, control, and paralysis. It's the language of liars and demagogues and exaggerations. Let's talk about risks and goals. The language of opportunities. An approach of `curl | bash` takes a needless amount of risk to accomplish its goals. It can do far too many things, of which it actually needs to do a small subset. It offers a lot of opportunity for bad things to happen to seize the opportunity for the things we want. Maybe there are ways to do the same things, to get the same ends, without taking on so much risk. How do you feel about this subject?
    • sanbor 8y ago
      Good question. The specific problem that I'd like to tackle is sharing code as safe as possible. The happy path is that you have some code to share and I want to get it exactly as you wrote it. Right now the current issues with just using GitHub to share your code are the following: 1. GitHub app gets hacked and let's someone else do a commit (like the rails hack mentioned above). 2. GitHub employee modifies files in prod servers. 3. GitHub cloud provider gets hacked 4. State actor with lots of resources MITM GitHub.com domain and internet traffic and you fetch something else. I think all this problems could be solved if: 1. Git enforces that all commits must be signed. 2. There is a decentralized list of usernames and keys. This feature doesn't exists in git but it would be great if you could run `git clone` and it rejects the cloning if not all commits and tags has been signed. But what If someone hacked GitHub to add a commit and she or he signed the commit. We need some kind of CA to only accept signed commits from the right people. So there should be a fixed list of committers allowed in the repo and git would have to enforce that as well. Then you have the problem that if all public keys are stored in GitHub then you almost get back to all the problems again of GitHub getting hacked. It would be great to have as many copies of usernames and public keys as possible. Something like a blockchain would be a good fit. To recap, by having a decentralized system of users and public keys, and making git validate that the commits are signed and from the right people, we could have a much more reliable way of sharing code. Additionally, we could have an "audit" system on top of all this were users can review code and mark it as "good". Then if you have a repo with a tagged version that has 5 reviews you can hope that it's pretty safe to run that version. Because it's a single system of usernames, you can check who are the reviewers. It might be a bad idea to `curl | bash` a script from an stranger but at least you remove the risks of your code being delivered by a third party.