On 08/28/2014 12:28 PM, John Stultz wrote:
So, this is a gentle reminder that use of git:// protocol by is
discouraged for Linaro engineers, and completely unsupported(*1) for third parties. Based on the analysis and outcome of the current DoS-like activity, we may need to make git:// access more limited and strict. So, please kindly:
So why does this affect us but not kernel.org?
We are still trying to understand this. We have some ideas for coping with this I've detailed at the bottom of this reply.
I'd mention that google doesn't support the git protocol and github is trying to discourage the usage by not advertising git:// links.
We already went through one painful transition where our URLs got scrambled, and I've had a few situations where folks have just recently realized that we still had trees, but the URLs were just different. So its quite frustrating to have to go through that again.
NOTE: its discouraged, not prevented.
What would be required to just make the git:// urls work properly?
Is this mainly an issue with the Android repos? If we reduce the git:// url load on the wort users, would that improve things enough? Do you have stats on which trees are hardest hit?
So far we've just had two attacks. The user was hitting multiple repos - I don't think it really had to do with a specific tree. This was against git.linaro.org, but the android server suffers from the same vulnerability.
We do have to try and take some steps to mitigate this risk right now. I'm sending out a separate email to the company on this, but let me say briefly:
1) Right now, my team is just looking at the problem mostly manually to identify when these attacks occur. We've come up with a quick way to block the attack that should allow the server to keep running for everyone else.
2) As #1 doesn't scale, we'd also like to change how the server is configured. The git-daemon itself only has logic for throttling a total number of concurrent connections. This allows a single user to still be able DoS us.
We'd like to create a new iptables rule that will only allow 3 concurrent connections to port 9418 from an IP address not in our EC2 cloud. Based on the previous attacks we've had this should mitigate our risk while also letting CI jobs run how they always have.
(*1) Unsupported in the current context means that "git://" URLs are not published in up-to-date information, and there's no warranty that any 3rd party will be able to complete a clone successfully using this protocol.
So as someone who has sent git pull requests in the past with the git urls, this is terrifying (and makes me hesitant to further use the linaro infrastructure). Do you have a pointer to why the git urls aren't coherent?
I'm not sure what Paul meant here. I see no reason why the git url's would become invalid for as long as we support the native git protocol.