3 ms·

I honestly don't find this reasoning very convincing. Mostly because it seems to be mistakenly equating Github with Git. All of the issues presented on both sid

by awj 15y ago

I honestly don't find this reasoning very convincing. Mostly because it seems to be mistakenly equating Github with Git. All of the issues presented on both sides (i.e. "why are we depending on this third party" and "I don't want to go back to <propriety whatever>") could be addressed with an in-house git repository. Sure that creates new problems, but if the concern is about using Github turning things into an argument about Git is just wasting time. Also, statements like "Listen, Github is how software is done right now" are just screaming for unnecessary confrontation and useless sideline arguments. I agree that Git is more effective (for most use cases) than any centralized VCS I've seen, but turning that opinion into a bald assertion is just going to cause arguments you really shouldn't be having.

glennericksen 15y ago
GitHub is great because you get to use git. I don't think that you can entirely separate them from each other, or craft an argument for the advantages of GitHub without somehow mentioning git. The vulnerability in GitHub clearly matters. It was a potentially explosive issue, but GitHub issued a prompt and appropriate mea culpa, while resolving the problem. Also, it stirred the pot in the Rails community, with many coming up with safeguards against the potential mass assignment vulnerability. Although I disagree with his downplaying of the problem, I certainly don't have plans of going anywhere else, which I think is the spirit of what the author was trying to convey.
- awj 15y ago
  > GitHub is great because you get to use git. That's exactly my point. The article seems to be confusing a concern about Github for a concern about Git and then spends most of its time addressing the latter. I can (and do!) use Git without using Github. If my organization decides that Github is too much of a risk, that doesn't necessarily mean we'll be dropping Git.
cbs 15y ago
I found the same thing, the whole article is incredibly weak. He asked with a sort of cocky, corporate assumption that I too was as appalled as he was at the blantant disregard for security [...] it was clear from the way he was talking about version control that he longed for the days of centralized control where one guy had to manually merge in everyone’s changesets There is a gigantic gulf between being appalled at github's security and wanting to go back to the days one guy was merging all changes by hand. it wouldn’t be tough to convince some manager-type that this Github thing does deserve a second-look. Maybe thats because it is worth taking a second look? Who's going to be convinced by a laundry list that boils down to "shit happens, luckily nothing bad happened this one time and it could never be completely catastrophic"? Thats a incredibly low bar to set. I love github, its well tailored to be a host for an open-source master, but not for private stuff; even if we were willing to host internal services outside the trusted network, I certainly couldn't trust github.
Xylakant 15y ago
Point 7 is dangerously wrong. The vulnerability allowed a malicious user to commit code under the identity of a a friendly user. The attacker could not have altered history, but he could have pushed his exploit on top. Chances are that it might have passed as a legitimate commit by that person.
- eridius 15y ago
  That's assuming nobody ever looks at anyone else's commits. Inserting an exploit into someone else's software by pushing a new commit on top is extremely risky, because it's highly likely that someone will actually look at the commit and notice it's doing something wrong. Inserting malicious commits into the history of a repository is what an attacker would love to do, because nobody is going to pore over the old history of the repo, and this is exactly what git is going to prevent.
  - awj 15y ago
    I don't trust the "many eyeballs" approach anywhere near that much. I doubt that a lot of people will look too closely at something dhh supposedly committed, and even if they were worried by what they saw they may put trust in the system (and the "developer") and decide that they're simply misreading it. Bottom line is "someone will probably see the exploit" is a gambler's approach to security.
  - Xylakant 15y ago
    Well, take a shotgun approach, insert vulnerabilities in multiple repos. Or obfuscate the attempt - insert a small vulnerability in one of the libraries that rails uses (let's take a mailer lib) and that only gets triggered when certain obscure preconditions are met and then push a commit on top of rails that creates the required preconditions. Instant exploit - and each commit by itself may very well look innocent. Or spread the exploit over multiple commits, each one innocent enough, each one with a different user. Be creative, you'll find a way. And even if it's caught, then the risk fingers pointing at you will be minimal.

by awj 15y ago

glennericksen 15y ago

GitHub is great because you get to use git. I don't think that you can entirely separate them from each other, or craft an argument for the advantages of GitHub without somehow mentioning git. The vulnerability in GitHub clearly matters. It was a potentially explosive issue, but GitHub issued a prompt and appropriate mea culpa, while resolving the problem. Also, it stirred the pot in the Rails community, with many coming up with safeguards against the potential mass assignment vulnerability. Although I disagree with his downplaying of the problem, I certainly don't have plans of going anywhere else, which I think is the spirit of what the author was trying to convey.

awj 15y ago
> GitHub is great because you get to use git. That's exactly my point. The article seems to be confusing a concern about Github for a concern about Git and then spends most of its time addressing the latter. I can (and do!) use Git without using Github. If my organization decides that Github is too much of a risk, that doesn't necessarily mean we'll be dropping Git.

cbs 15y ago

I found the same thing, the whole article is incredibly weak. He asked with a sort of cocky, corporate assumption that I too was as appalled as he was at the blantant disregard for security [...] it was clear from the way he was talking about version control that he longed for the days of centralized control where one guy had to manually merge in everyone’s changesets There is a gigantic gulf between being appalled at github's security and wanting to go back to the days one guy was merging all changes by hand. it wouldn’t be tough to convince some manager-type that this Github thing does deserve a second-look. Maybe thats because it is worth taking a second look? Who's going to be convinced by a laundry list that boils down to "shit happens, luckily nothing bad happened this one time and it could never be completely catastrophic"? Thats a incredibly low bar to set. I love github, its well tailored to be a host for an open-source master, but not for private stuff; even if we were willing to host internal services outside the trusted network, I certainly couldn't trust github.

Xylakant 15y ago

Point 7 is dangerously wrong. The vulnerability allowed a malicious user to commit code under the identity of a a friendly user. The attacker could not have altered history, but he could have pushed his exploit on top. Chances are that it might have passed as a legitimate commit by that person.

eridius 15y ago
That's assuming nobody ever looks at anyone else's commits. Inserting an exploit into someone else's software by pushing a new commit on top is extremely risky, because it's highly likely that someone will actually look at the commit and notice it's doing something wrong. Inserting malicious commits into the history of a repository is what an attacker would love to do, because nobody is going to pore over the old history of the repo, and this is exactly what git is going to prevent.
- awj 15y ago
  I don't trust the "many eyeballs" approach anywhere near that much. I doubt that a lot of people will look too closely at something dhh supposedly committed, and even if they were worried by what they saw they may put trust in the system (and the "developer") and decide that they're simply misreading it. Bottom line is "someone will probably see the exploit" is a gambler's approach to security.
- Xylakant 15y ago
  Well, take a shotgun approach, insert vulnerabilities in multiple repos. Or obfuscate the attempt - insert a small vulnerability in one of the libraries that rails uses (let's take a mailer lib) and that only gets triggered when certain obscure preconditions are met and then push a commit on top of rails that creates the required preconditions. Instant exploit - and each commit by itself may very well look innocent. Or spread the exploit over multiple commits, each one innocent enough, each one with a different user. Be creative, you'll find a way. And even if it's caught, then the risk fingers pointing at you will be minimal.