Hi Lukas, On Mon, Feb 02, 2015 at 10:06:43PM +0100, Lukas Tribus wrote: > >>> There is no SSL protected repo. I'm surprized that you found the > >>> haproxy.org > >>> site slow, usually it's reasonably fast. Are you sure you weren't > >>> cloning from 1wt.eu instead, which is the slow master ? > >>> > >> > >> Would it be possible to get the haproxy org on github to be synced with > >> your repos. > > > > Haproxy.org is supposed to be synced. Github's haproxy account doesn't > > belong to me and is not an official one (and it's different). > > Since there is also a "haproxy" github-organisation behind this github fork, > it does look like it would be an official mirror and I can see why it > attracts bug reports on the github issue tracker for those repositories and > merge requests on github instead of the mailing list. Thats bad, very bad.
Yes I know, but you can never spend your time registering a project's name on each and every new site that appears everywhere, and once the site becomes big and you start to care, it's too late. So we all have to deal with this. > For anyone forking or mirroring a particular piece of code: please do not > impersonate the author or the project. Make it abundantly clear that the > mirror is unofficial (not only in the description or README, but in the > title). > > I'm CC'ing Jeff Buchbinder since he seems to be the one merging real haproxy > git back to this github fork. Jeff used to maintain packages for some distros, so it's not as if he was a complete stranger to the project. I think that the problem only lies with his haproxy repository which contains extra commits. I don't know if it's possible to rename repositories on github, but calling it "haproxy-jeff" and having a mirror of the official one in the "haproxy" name would make things better already. I don't know if it's possible to tag some repos as mirrors to disable pull requests there. > >> That might provide a nice SSL protected location. > > > > It will bring absolutely nothing > > I tend to disagree: > > > 1) trees are replicated to multiple places > > Of course the actual replication would have to be protected as-well, not > just the download from the mirror. SSH or HTTPS as a transport protocol > will do that. You'd get conflicts, expectected merges, or differences when you merge if you retrieve a wrong repository which was tampered with. The only case where it could make sense is during the clone, and given that people clone from various places, protecting the transport from a single location will never protect all other ones. And the fact that https://github.com/haproxy/haproxy serves a different content is the first proof of this :-) > > and 2) the git structure by itself provides protection. > > I don't see how it can protect against a MITM'ed git mirror that is serving > tainted repositories. cf above. > > However SSL would be even slower and more resource intensive. > > I believe the performance penalty of SSL is neglectable. > > Lets look at some numbers: > >From my box here I have about 55ms of RTT to git.haproxy.org and > 115ms RTT to github.com (the latter crosses the atlantic). > > If I clone via unprotected HTTP from git.haproxy.org I need about > 2 and a half minutes. > > If I clone via protected HTTPS from the github.com fork (which is not > exactly the same, but not that different either) I need about 30 seconds. > > So although the RTT to github is about twice as much and we use HTTPS > instead of HTTP, it still is about five times faster than git.haproxy.org. OK, agreed on this one. > This is most likely due to the plain-HTTP usage instead of git-over-HTTP, > as Warren mentioned. Yes. > Do we absolutely need that kind of speed? No. I'm just saying that performance > is not a showstopper for SSL, especially in this case. > > > And would require a cert and careful maintenance. > > Correct, unless we would use something like github ourselfs. That would > mean leveraging their platform for all those nice things like HTTPS and > git-over-HTTP, without the actual maintenance burden. Well, to me it's the opposite in fact : using github *becomes* a maintenance burden. I'm sorry but I definitely cannot resolve myself to have to launch a browser to have to do some development. And despite the fact that I love what github has achieved and that I have a great respect for their work, I really find their interface absolutely unusable. It has nothing to do with git, and that's probably why it succeeded. Git is really painful if you don't use it everyday but when you get used to it, it's marvelous and helps you make your job blazingly fast. Github is more something like "git for dummies". You don't have to know anything about git or even versionning, it will help you do it safely. But when you know how to use git, it's too cumbersome to find your way through it. When I have to use it for the IETF HTTP-bis WG, I find it takes me on average 4 times the time it would usually take to do basic tasks such as commenting proposed changes, what a mess! And it manages to be even slower to display a list of shortened commits than haproxy.1wt.eu which is on my ADSL line, which I find a bit funny considering how many people have been complaining about its speed in the past :-) > That requires, of course, trusting github. > > What this would also bring to the table is a bug-tracker with strong ties > to git (but is of course github-proprietary). I have absolutely no problem trusting them. They're serious, they're doing a great job, and even from the private exchanges I have with the team, I can say that they're taking their job very seriously and are quite proactive on any problem which seems to appear, so I have no reason for being afraid of this. It's just that it's not the right tool for the job on my side *at all*. There's no one-size-fits-all anyway. However I welcome people to clone the repositories overthere and regularly update them as Jeff seems to be doing, provided that they're not altered, otherwise it becomes quite confusing for users (and that's where I think Jeff should try to do something). And if that helps getting extra tools for free such as a bug tracker or anything, that's fine! Best regards, Willy
