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

[Guilhem Moulin]

On Tue, 23 Oct 2018 at 09:42:54 +0200, Lionel Elie Mamane wrote:
> 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?)

Another (theoretic) attack vector is to strip a reference from the
initial git-upload-pack advertisement so the dev doesn't get a bugfix or
something; at least not until said dev relocates to a safer network.
 
> (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.)

One way is to add https:// to form action fields.  Not suggesting that
we do that, though :-)  If GET requests are served over plaintext links
even for authenticated users, then an eavesdropper could sniff session
cookies and hijack connections.
 
> 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",

One has to pay the the full TLS overhead for each `git fetch` (AFAIK
libcurl doesn't do session sharing across processes.).  And the full
SSH2 overhead for each `git push`, modulo connection multiplexing.

> "load a complete web page with all images, javascript, dependencies,
> etc", "post an answer to a gerrit change",

Login form aside, all content is served from the gerrit box, so a single
connection is used to serve all resources on a given page.  And our
server is configured to cache TLS sessions IDs, so clicking around
doesn't cost an extra handshake for each page.

>> 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.

You're right, it was probably a few years before that.  Perhaps the main
changes of the past few years is public perception.  For reference,
GMail defaulted to https:// in early 2010 [0], Facebook in summer 2013
[1] (feeling the heat of the Snowden leaks?), Wikipedia in early 2015
(2013 for authenticated users) [2]

> Many public key crypto operations per seconds is (was?) another issue
> altogether.

Is, esp. for RSA (we're not using EdDSA currently).

-- 
Guilhem.

[0] https://gmail.googleblog.com/2010/01/default-https-access-for-gmail.html
    https://transparencyreport.google.com/https/overview
[1] https://www.facebook.com/notes/facebook-engineering/secure-browsing-by-default/10151590414803920/
[2] https://blog.wikimedia.org/2015/06/12/securing-wikimedia-sites-with-https/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <https://lists.freedesktop.org/archives/libreoffice/attachments/20181023/4996ac72/attachment.sig>