Re: [TDF infra] Announcing Gitiles VCS browser (gitweb replacement) and https:// anon git URIs

On Tue, Oct 23, 2018 at 07:34:54AM +0200, Guilhem Moulin wrote:
> On Mon, 22 Oct 2018 at 17:25:11 +0200, Lionel Elie Mamane wrote:
> > On Mon, Oct 22, 2018 at 04:33:21PM +0200, Guilhem Moulin wrote:

> > > Might be orthogonal to the git:// vs. https:// vs. ssh://
> > > discussion.  Gerrit uses JGit as Git implementation, while
> > > git-daemon(1) spawns “normal” (C-based) git-upload-pack(1)
> > > processes.

> > For us developers of LibreOffice, and thus consumers of the Gerrit
> > / Git service of freedesktop.org and TDF, whether the difference
> > comes from the protocol itself or a different git implementation on
> > the server to serve the different protocols is intellectually
> > interesting (thanks for that!), but materially inconsequential: if
> > using git: will be faster, we will use git:.

> Following the same logic, you want gerrit.libreoffice.org to serve
> content over plain http:// so you can save the two round-trips when
> you launch your browser to submit your reviews? Oo

Submission (write access) is something else entirely than code
download (read access); the security requirements are massively
different. (Yes, I would prefer to be certain that the code I get is
the right one; however, if I don't and try to submit a patch on top of
code that is not the on in the TDF repo, it will fail. Unless the
attacker also constructed git that exploits SHA collisions?)

(The above analysis does not apply to gerrit-as-a-website, because
 there the link between the code I see and the code I approve is not
 on my local machine, but depends on the security of the connection;
 and because I don't know how to secure reading but not writing on a
 website.)

If it is only two round-trips per operation, I'm likely to not notice
and thus be perfectly happy to use whatever protocol. If the two round
trips are multiplied by many many requests to serve one operation,
then I may notice. Where "operation" is one action for the user, not
one action for the program. E.g., "git fetch", "git push", "load a
complete web page with all images, javascript, dependencies, etc",
"post an answer to a gerrit change", as opposite to "get one
commit / changepack among 2473 to be downloaded", "get one image / one
javascript file", etc.

> Things have changed since 2012, encryption is faster (there are
> modern stream ciphers and hardware acceleration is more widespread),
> and for situations like this one there is no reason not to encrypt
> data in transit.

I would have thought symmetric encryption already wasn't a bottlneck,
at least on the client side (maybe on the server side it was?) in
2012; I think one could even back then easily saturate a 100Mbps
connection using less than 100% of one core of an entry-level desktop
CPU. Many public key crypto operations per seconds is (was?) another
issue altogether.

Possibly the difference I was very clearly feeling back then was
C git vs JGit, and not having a clue that different implementations
were being used, were just carelessly blamed on crypto overhead.

> > > Anyway, it's easy enough to benchmark no-op `git fetch` on core.
> > > master is currently at c99732d59bc6, and I'm fetching from the
> > > same datacenter to avoid metrics being polluted with network
> > > hiccups.

> > Yes, but no. You also test in an environment where a network RTT is
> > probably about one fifth to one third of a millisecond, and
> > bandwidth at least 100Mbps if not 1000Mbps? In that case,
> > everything will be fast. Time difference will be lost in noise.

> I was arguing that C git and Jgit's performances are
> indistinguishable on the current instance.

Ah, I understand now.

> Counting round-trips for SSH isn't trivial, but let me try:
> (...)  So if the latency is symmetric and the first key offered is
> accepted by the server, that makes a constant overhead of 8.5
> round-trips. (... ) Additionally, the sending side must wait for the
> client to adjust the window size when it's full.

Since we were feeling a difference between git: and ssh:, not between
git: and http(s): (which we didn't even consider), possibly that's
also a factor.

-- 
Lionel