Hacker News new | past | comments | ask | show | jobs | submit login

Github and bitbucket etc really should offer an opt-out scan-on-push service that looks for the most common mistakes and reject the push with an URL explaining what's going on in the server echo.

FWIW, AWS actually does this for you. Their response time is pretty amazing, too. IIRC, they caught me pushing an active key within 2-3 minutes.

That's pretty sweet, but by then the damage's already done. Rejecting the push would be even better, making sure the confidential data never goes public. AIUI dark-hatted people are scraping the real-time push feeds at Github for credentials and botting up exploits, so even a few seconds could be a big enough window for damage to be done.

An example of this happening on AWS just like you mentioned: https://www.humankode.com/security/how-a-bug-in-visual-studi...

I was just thinking of this exact story when the grandparent mentioned AWS. They have a huge financial interest in automatically detecting this kind of thing.

I mean, obviously AWS can't reject your pushes, so it's the best they can do, but I agree that it would be nice if Github did this as well.

> That's pretty sweet, but by then the damage's already done.

I'm not sure that's true. I was able to disable the key before anyone used it (although it was locked down so far that they couldn't have charged anything to my account, since I didn't trust the code I was testing with real money).

Github invalidates your API token if it is pushed in one of your repos. Pretty handy.

There's been _alot_ of comments here and elsewhere that state the exact same thing. On one hand, no it's not their fault and _should_ they be held accountable - obviously no. But it would be so awesome if they did provide this. Wherever human error can occur, it will occur.

I wonder what kind of load that'd place on Github's Git daemons, though? Might be difficult to do for free.

No too much load, really. We (Bitbucket) already have pre-receive hooks for a handful of other things. The trick would be defining the rules properly to have a reasonably low false negative rate while avoiding work inhibiting false positives (or allow for a mechanism to override it with, say, a force push).

Of course, 93% of our repositories are private so this feature may not be exceedingly useful to our customers vs other things we could be spending our time on.

Edit: I shouldn't have said not useful, rather, comparatively there may be more value in us pursuing other work first. E.g., provide a mechanism for 3rd party pre-receive hooks via our add-on system.

It is still useful. Even if the repository is private, it can be shared with people who shouldn't have that private key.

Interesting to see that percentage of repos is private.

Is BitBucket separate from Atlassian? Are you hiring? ;)

We're very focused on professional teams working on private projects -- but you can't see that because they're all private. Bitbucket is sort of like an iceberg: 1. you can only see a small percentage of the of the total mass; 2. it is blue.

Yes, we're part of Atlassian and we're hiring in San Francisco.

Can't afford to move to SFO unfortunately - any plans to expand remote work?

FWIW Github already scans your commits for Github OAuth tokens and revokes any tokens it found. Doesn't prevent you from checking in SSH keys or anything like that but it's something, right? (Source: I did this once with a non-priviledged token. Oops.)

Yeah, definitely hard to do for free probably, but it's a potentially great value add, and could be an additional service an organization/user could pay for.

Applications are open for YC Summer 2019

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact