From: Konstantin Khomoutov <flatworm@users.sourceforge.net>
To: Sergey Sharybin <sergey.vfx@gmail.com>
Cc: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>,
Andreas Schwab <schwab@linux-m68k.org>,
Konstantin Khomoutov <flatworm@users.sourceforge.net>,
Git List <git@vger.kernel.org>
Subject: Re: git:// protocol over SSL/TLS
Date: Fri, 27 Dec 2013 18:39:58 +0400 [thread overview]
Message-ID: <20131227183958.b8e55d7e3c8c38b46137ea9c@domain007.com> (raw)
In-Reply-To: <CAErtv25URyB3znN1CMd87374NUjaSFvg=cee_-c=s8bB2j052A@mail.gmail.com>
On Fri, 27 Dec 2013 20:25:16 +0600
Sergey Sharybin <sergey.vfx@gmail.com> wrote:
> Security in this case is about being sure everyone gets exactly the
> same repository as stored on the server, without any modifications to
> the sources cased by MITM.
>
> As for "smart" http, this seems pretty much cool.However, we're
> currently using lighthttpd, so it might be an issue. We'll check on
> whether "smart" http is used there, and if not guess it wouldn't be a
> big deal to switch to apache.
The web server software has nothing to do with HTTP[S] used by Git being
"smart", I think, it just has to be set up properly.
As discussed in an earlier thread here, a good indication of the
dumb version of the protocol being in use is no display of the
fetching progress on the client while doing `git clone` because this
information (like "compressing objects ..." etc) is sent by the
server-side Git process which is only there if HTTP[S] "was smart".
Otherwise the client just GETs packs of objects, traverses them, GETs
more and so on, so batches of HTTP GET requests correlating to clone
sessions in the web server logs should also be indicative of the
problem.
next prev parent reply other threads:[~2013-12-27 14:40 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-27 12:59 git:// protocol over SSL/TLS Sergey Sharybin
2013-12-27 13:29 ` Andreas Schwab
2013-12-27 13:36 ` Konstantin Khomoutov
2013-12-27 13:58 ` Sergey Sharybin
2013-12-27 14:12 ` Andreas Schwab
2013-12-27 14:16 ` Konstantin Khomoutov
2013-12-27 14:18 ` Sergey Sharybin
2013-12-27 14:20 ` Matthieu Moy
2013-12-27 14:25 ` Sergey Sharybin
2013-12-27 14:39 ` Konstantin Khomoutov [this message]
2013-12-27 14:47 ` Sergey Sharybin
2013-12-27 14:56 ` Konstantin Khomoutov
2013-12-28 9:37 ` Jeff King
2013-12-27 16:26 ` Bernhard R. Link
2013-12-28 20:52 ` Sergey Sharybin
2013-12-28 0:11 ` brian m. carlson
2013-12-27 14:29 ` Andreas Schwab
2013-12-27 14:21 ` Pyeron, Jason J CTR (US)
2013-12-27 14:14 ` Konstantin Khomoutov
2013-12-27 22:21 ` Junio C Hamano
2013-12-28 20:00 ` Ilari Liusvaara
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20131227183958.b8e55d7e3c8c38b46137ea9c@domain007.com \
--to=flatworm@users.sourceforge.net \
--cc=Matthieu.Moy@grenoble-inp.fr \
--cc=git@vger.kernel.org \
--cc=schwab@linux-m68k.org \
--cc=sergey.vfx@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).