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
wrote:
> * Sergey Sharybin [131227 15:25]:
>> Security in this case is about being sure everyone gets exactly the
>> same repository as stored on the server, wi
On Fri, Dec 27, 2013 at 02:21:31PM -0800, Junio C Hamano wrote:
> Konstantin Khomoutov 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 and setup on both ends
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 do
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 differen
Konstantin Khomoutov writes:
> On Fri, 27 Dec 2013 18:59:00 +0600
> Sergey Sharybin 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
* Sergey Sharybin [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
man-in-the-middle. Ge
On Fri, 27 Dec 2013 20:47:54 +0600
Sergey Sharybin 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
> > information (like "c
>> 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
On Fri, 27 Dec 2013 20:25:16 +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.
>
> As for "smart" http, this seems pretty much cool.However, we're
Matthieu Moy 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.
--
Andreas Schwab, sch...@lin
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
w
Andreas Schwab writes:
> Sergey Sharybin 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 added security by using TLS for
> tra
> -Original Message-
> From: Andreas Schwab
> Sent: Friday, December 27, 2013 9:12 AM
>
> Sergey Sharybin 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 ou
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 :)
On Fri, 27 Dec 2013 15:12:07 +0100
Andreas Schwab 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 by using TLS f
On Fri, 27 Dec 2013 19:58:19 +0600
Sergey Sharybin 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" which is not
Sergey Sharybin 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 added security by using TLS for
transport.
Andreas.
--
Andreas Schwab
Hi,
On Fri, Dec 27, 2013 at 7:36 PM, Konstantin Khomoutov
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 question
> was about a gen
On Fri, 27 Dec 2013 18:59:00 +0600
Sergey Sharybin 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). Unfortunately
Sergey Sharybin 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 secure
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 the
21 matches
Mail list logo
