>>> 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.
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.
>> 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.
> 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.
> 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.
This is most likely due to the plain-HTTP usage instead of git-over-HTTP,
as Warren mentioned.
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. 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).
Regards,
Lukas
