Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when storing it on the
returned descriptor. As a result, by the time this field is used (in
transactions of file
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
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
Am 26.12.2013 16:58, schrieb Jonathan Nieder:
This patch series comes from
https://github.com/jlehmann/git-submod-enhancements branch
recursive_submodule_checkout. It needed some tiny tweaks to apply to
current master and build without warnings, but nothing major, and I
haven't sanity
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).
Am 26.12.2013 17:02, schrieb Jonathan Nieder:
From: Jens Lehmann jens.lehm...@web.de
Date: Mon, 18 Jun 2012 22:17:59 +0200
This commit adds the functions needed for configuration, for setting the
default behavior and for determining if a submodule path should be updated
automatically.
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
Am 26.12.2013 17:12, schrieb Jonathan Nieder:
From: Jens Lehmann jens.lehm...@web.de
Date: Tue, 19 Jun 2012 20:55:45 +0200
Implement the functionality needed to enable work tree manipulating
commands to that a deleted submodule should not only affect the index
(leaving all the files of 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
Am 26.12.2013 17:22, schrieb Jonathan Nieder:
From: Jens Lehmann jens.lehm...@web.de
Date: Wed, 13 Jun 2012 18:50:10 +0200
Signed-off-by: Jens Lehmann jens.lehm...@web.de
Signed-off-by: Jonathan Nieder jrnie...@gmail.com
---
This is the patch that actually introduces the
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
Roman Kagan wrote:
Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when storing it on the
returned descriptor. As a result, by the time this field is used (in
Jonathan Nieder jrnie...@gmail.com wrote:
Roman Kagan wrote:
Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when storing it on the
returned descriptor.
Support for grafts predates Git's strbuf, and hence it is understandable
that there was a hard-coded line length limit of 1023 characters (which
was chosen a bit awkwardly, given that it is *exactly* one byte short of
aligning with the 41 bytes occupied by a commit name and the following
space or
Hi,
Johannes Schindelin wrote:
While regular commit histories hardly win comprehensibility in general
if they merge more than twenty-two branches in one go, it is not Git's
business to limit grafts in such a way.
Fun. :) Makes sense.
[...]
---
builtin/blame.c | 8
commit.c
Johannes Schindelin johannes.schinde...@gmx.de writes:
Support for grafts predates Git's strbuf, and hence it is understandable
that there was a hard-coded line length limit of 1023 characters (which
was chosen a bit awkwardly, given that it is *exactly* one byte short of
aligning with the 41
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration
Johannes Schindelin wrote:
it returns EOF only if ch == EOF *and* sb-len == 0, i.e. if no characters
have been read before hitting EOF.
Yep. api-strbuf.txt even says so. Sorry for the nonsense.
For what it's worth,
Reviewed-by: Jonathan Nieder jrnie...@gmail.com
--
To unsubscribe from this
Eric Sunshine sunsh...@sunshineco.com writes:
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano gits...@pobox.com wrote:
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the
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
Eric Wong normalper...@yhbt.net writes:
Jonathan Nieder jrnie...@gmail.com wrote:
Roman Kagan wrote:
Subversion serf backend in versions 1.8.5 and below has a bug that the
function creating the descriptor of a file change -- add_file() --
doesn't make a copy of its third argument when
Johannes Schindelin wrote:
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Is this easy to reproduce so some interested but lazy person could
write a test?
Yep. Make 25 orphan commits, add a graft line to make the first a merge of
the rest.
Thanks. Here's a pair of tests doing that.
Hi Jonathan,
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Johannes Schindelin wrote:
it returns EOF only if ch == EOF *and* sb-len == 0, i.e. if no characters
have been read before hitting EOF.
Yep. api-strbuf.txt even says so.
I never bothered to look ;-)
Sorry for the nonsense.
Hi Jonathan,
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Johannes Schindelin wrote:
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Is this easy to reproduce so some interested but lazy person could
write a test?
Yep. Make 25 orphan commits, add a graft line to make the first a merge of
Wir bieten persönliche und geschäftliche Kredite ohne Sicherheiten (nur
Identifikation) mit 3 % Zinssatz, von ? 10.000, ? 90,000,000 in 1 Jahr auf 20
Jahre
Laufzeit. !!bewerben Sie sich jetzt!
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
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
Jonathan Nieder jrnie...@gmail.com writes:
Johannes Schindelin wrote:
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
Is this easy to reproduce so some interested but lazy person could
write a test?
Yep. Make 25 orphan commits, add a graft line to make the first a merge of
the rest.
Thanks.
On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano gits...@pobox.com wrote:
Duy Nguyen pclo...@gmail.com writes:
On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano gits...@pobox.com wrote:
Do we even need to expose them as ref-like things as a part of the
external API/UI in the first place? For
37 matches
Mail list logo
