On Fri, Dec 27, 2013 at 08:47:54PM +0600, Sergey Sharybin wrote:
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.
Misunderstood git doc then which says it has to be Apache, currently
- other CGI servers don't work,
On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote:
Konstantin Khomoutov flatw...@users.sourceforge.net writes:
The Git protocol does not implement it itself but you can channel it
over a TLS tunnel (via stunnel for instance). Unfortunately, this
means a specialized software
Yeah, i understand this. We can not protect self from every single
possible attack..
On Fri, Dec 27, 2013 at 10:26 PM, Bernhard R. Link
brl+...@mail.brlink.eu wrote:
* Sergey Sharybin sergey@gmail.com [131227 15:25]:
Security in this case is about being sure everyone gets exactly the
same
Hello everyone!
Quick question is, is it possible to use git:// protocol over
SSL/TLS/other secure transport?
Or the recommended way to do secure anonymous checkout is to simply
use https:// ?
Thanks in advance!
--
With best regards, Sergey Sharybin
--
To unsubscribe from this list: send
Sergey Sharybin sergey@gmail.com writes:
Quick question is, is it possible to use git:// protocol over
SSL/TLS/other secure transport?
The git protocol itself performs no encryption or authentication by
design. This is the job of the transport protocol.
Or the recommended way to do
On Fri, 27 Dec 2013 18:59:00 +0600
Sergey Sharybin sergey@gmail.com wrote:
Quick question is, is it possible to use git:// protocol over
SSL/TLS/other secure transport?
The Git protocol does not implement it itself but you can channel it
over a TLS tunnel (via stunnel for instance
Hi,
On Fri, Dec 27, 2013 at 7:36 PM, Konstantin Khomoutov
flatw...@users.sourceforge.net wrote:
The Git protocol does not implement it itself but you can channel it
over a TLS tunnel (via stunnel for instance). Unfortunately, this
means a specialized software and setup on both ends so if the
On Fri, 27 Dec 2013 19:58:19 +0600
Sergey Sharybin sergey@gmail.com wrote:
[...]
Yes, but it will only be secure if you've managed to verify the
server's certificate and do trust its issuer (or a CA higher up the
cert's trust chain) -- people tend to confuse encrypted with
secure
On Fri, 27 Dec 2013 15:12:07 +0100
Andreas Schwab sch...@linux-m68k.org wrote:
So guess we just need to recommend using https:// protocol instead
of git:// for our users?
Given how easy it is to verify the integrity of a git repository out
of band there isn't really much of added security
Our sysadmns are mainly worried about possible MITM which might give
users completely wrong repo.
For sure users might simply compare hash of HEAD from https'ed site
with repo browser with what they've got in the checkout. But that's an
extra step which we'd like to avoid without security harm :)
-Original Message-
From: Andreas Schwab
Sent: Friday, December 27, 2013 9:12 AM
Sergey Sharybin sergey@gmail.com writes:
So guess we just need to recommend using https:// protocol instead of
git:// for our users?
Given how easy it is to verify the integrity of a git
Andreas Schwab sch...@linux-m68k.org writes:
Sergey Sharybin sergey@gmail.com writes:
So guess we just need to recommend using https:// protocol instead of
git:// for our users?
Given how easy it is to verify the integrity of a git repository out of
band there isn't really much of
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
Matthieu Moy matthieu@grenoble-inp.fr writes:
You can verify integrity after the fact, but not guarantee
confidentiality ... so it again depends on the definition of security.
Since the OP is talking about anonymous access there is no need for
confidentiality in this case.
Andreas.
--
On Fri, 27 Dec 2013 20:25:16 +0600
Sergey Sharybin sergey@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
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
On Fri, 27 Dec 2013 20:47:54 +0600
Sergey Sharybin sergey@gmail.com wrote:
[...]
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
* Sergey Sharybin sergey@gmail.com [131227 15:25]:
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.
Note that ssl (and thus https) only helps here against a resource-less
Konstantin Khomoutov flatw...@users.sourceforge.net writes:
On Fri, 27 Dec 2013 18:59:00 +0600
Sergey Sharybin sergey@gmail.com wrote:
Quick question is, is it possible to use git:// protocol over
SSL/TLS/other secure transport?
The Git protocol does not implement it itself but you can
On Fri, Dec 27, 2013 at 08:25:16PM +0600, Sergey Sharybin 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.
Besides security, HTTPS is more likely to work across different
20 matches
Mail list logo
