Date: prev next · Thread: first prev next last
2018 Archives by date, by thread · List index


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/

Attachment: signature.asc
Description: PGP signature


Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.