He didn't hack into any others' accounts, he simply (mis)used the service from his own. Suspending him is useless for security as he could set up another account in minutes.
I think the accounts mean organisations. For instance, he exploited this vulnerability to add his public key to the authorised rails user keys. He probably did this to two other "accounts". His exploit wasn't logging in or impersonating any other accounts AFAIK.
If I was in their shoes, I would have made the same call: he hacked into users accounts and threatened to do more damage, quick, bust out the bargepole
I would be very concerned about this backfiring, but, I would hack Rails a little to report when anybody attempts to use this glitch and wire that into Hubot(TM), so if he does attempt to use this same hole again, the devs are warned instantly
There was a post about doing the pragmatic thing versus the right thing on HN a little while ago. I can't think of a better scenario to illustrate that than this.
By pushing him out you create moral hazard for future users who discover vulnerabilities. You also, in the near term, risk pissing off the guy who found the vulnerability which could result in very real blowback.
I'm basing this on the assumption that he didn't do anything malicious, i.e. outside his own account. If he did then his near-term risk profile changes dramatically and the move would have been rational.
Funny, I thought you were going to argue that the other way. That the "right" thing to do is start a dialogue with him, but the pragmatic thing is to ban his account at least until you sort things out on your end. Guess that just shows how tricky these issues are.
Given a hacker who found a vulnerability, exploited it within his account, and publicised it we can conclude that (1) he is smart (or lucky), (2) he does not pose an immediate malicious threat, and (3) he has the potential to become a serious problem.
Engaging with him carries the benefit of understanding the vulnerability while opening a dialogue that mitigates the hacker mutating into a serious problem. It carries the cost of not being able to claim, as GH did, that it pro-actively identified the vulnerability and thus looking weak. It carries the risk of giving the hacker time to rummage through more of the system.
Suspending him carries the benefit of being able to look strong while mitigating the risk of the hacker causing further damage. It carries the cost of losing a lot of emotional lee-way and thus future conversational runway with the hacker. It thus increases the risk of him turning into a serious problem in the shadows. There is also the risk that future users who happen upon vulnerabilities will think twice about publishing their finding under their real name.
Given, as many here have pointed out, that he can create a new account and be equally damaging (the risk is a property of him, not his account), the suspension offers no tangible benefit long-run benefit above that of managing perceptions. I don't know how sensitive GH's user base is to the perception of security.
The unknown here is whether GH has evidence that he acted maliciously, i.e. modified repos in accounts whose owners didn't give him permission to modify.
Suspending his account doesn't make any sense. He could easily sign up with another email account. Set up a new set of keys on another computer and he's back at it. GH should be working with him instead... he obviously knows what he's doing.
