On Fri, Dec 27, 2013 at 12:12 AM, Junio C Hamano wrote:
> Duy Nguyen writes:
>
>> On Sun, Dec 22, 2013 at 1:38 PM, Junio C Hamano 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 end-user scripts that want
>>> to operat
Jonathan Nieder 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 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
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 majord.
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 fir
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 non
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.
S
Eric Wong writes:
> Jonathan Nieder 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
>> > retu
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 it
> over a TLS tunnel (via stunn
Eric Sunshine writes:
> On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano 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 i
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
--
To unsubscribe from this list: send the l
On Thu, Dec 26, 2013 at 4:08 PM, Junio C Hamano 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 branches
> of the re
Johannes Schindelin 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 bytes occupied by a co
Hi,
On Fri, 27 Dec 2013, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
>
> [...]
> > ---
> > builtin/blame.c | 8
> > commit.c| 10 +-
> > 2 files changed, 9 insertions(+), 9 deletions(-)
>
> Is this easy to reproduce so some interested but lazy person could
> w
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
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
Jonathan Nieder 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. As a resul
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 (i
* 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
Am 26.12.2013 17:22, schrieb Jonathan Nieder:
> From: Jens Lehmann
> Date: Wed, 13 Jun 2012 18:50:10 +0200
>
> Signed-off-by: Jens Lehmann
> Signed-off-by: Jonathan Nieder
> ---
> This is the patch that actually introduces the --recurse-submodules
> option, which makes the rest work.
>
> The t
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
Am 26.12.2013 17:12, schrieb Jonathan Nieder:
> From: Jens Lehmann
> 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 submodule in t
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
Am 26.12.2013 17:02, schrieb Jonathan Nieder:
> From: Jens Lehmann
> 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.
>
> Signed-off-by:
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, this
mean
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
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 anonymous check
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 l
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 copyi
39 matches
Mail list logo
