Re: [PATCH 2/2] utf8: accept "latin-1" as ISO-8859-1

On Mon, Sep 26, 2016 at 06:22:11PM -0700, Junio C Hamano wrote: > Even though latin-1 is still seen in e-mail headers, some platforms > only install ISO-8859-1. "iconv -f ISO-8859-1" succeeds, while > "iconv -f latin-1" fails on such a system. > > Using the same fallback_encoding() mechanism

Re: [PATCH 1/2] utf8: refactor code to decide fallback encoding

On Mon, Sep 26, 2016 at 06:22:10PM -0700, Junio C Hamano wrote: > @@ -501,17 +516,9 @@ char *reencode_string_len(const char *in, int insz, > > conv = iconv_open(out_encoding, in_encoding); > if (conv == (iconv_t) -1) { > - /* > - * Some platforms do not have

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Mon, Sep 26, 2016 at 9:36 AM, Linus Torvalds wrote: > This looks very good to me, but I wonder if it couldn't be even more > aggressive. > > In particular, the only hashes that most people ever use in short form > are commit hashes. Those are the ones you'd use

Re: [PATCH 1/2] tree-walk: be more specific about corrupt tree errors

Jeff King writes: >> +test_expect_success 'malformed mode in tree' ' >> +test_must_fail git hash-object -t tree >> ../t1007/tree-with-malformed-mode 2>err && >> +grep "malformed mode in tree entry for tree" err >> +' > > This ".." will break when the test is run with

Re: [PATCH 2/2] fsck: handle bad trees like other errors

On Mon, Sep 26, 2016 at 03:32:45PM -0400, David Turner wrote: > Instead of dying when fsck hits a malformed tree object, log the error > like any other and continue. Now fsck can tell the user which tree is > bad, too. Cool. I think the lack of this is what made me drag my feet on the first

Re: [PATCH 1/2] tree-walk: be more specific about corrupt tree errors

On Mon, Sep 26, 2016 at 03:32:44PM -0400, David Turner wrote: > From: Jeff King > > When the tree-walker runs into an error, it just calls > die(), and the message is always "corrupt tree file". > However, we are actually covering several cases here; let's > give the user a hint

Re: [PATCH 1/3] tree-walk: be more specific about corrupt tree errors

On Mon, Sep 26, 2016 at 09:01:15PM -0700, Junio C Hamano wrote: > > 5 files changed, 21 insertions(+), 7 deletions(-) > > create mode 100644 t/t1007/.gitattributes > > create mode 100644 t/t1007/tree-with-empty-filename > > create mode 100644 t/t1007/tree-with-malformed-mode > > I hate to

[PATCH] xdiff: rename "struct group" to "struct xdlgroup"

Commit e8adf23 (xdl_change_compact(): introduce the concept of a change group, 2016-08-22) added a "struct group" type to xdiff/xdiffi.c. But the POSIX system header "grp.h" already defines "struct group" (it is part of the getgrnam interface). This happens to work because the new type is local to

Re: [PATCH 1/3] tree-walk: be more specific about corrupt tree errors

David Turner writes: > From: Jeff King > > When the tree-walker runs into an error, it just calls > die(), and the message is always "corrupt tree file". > However, we are actually covering several cases here; let's > give the user a hint about what

RE: git-upload-pack hangs

This is a very, very first draft. It is allowing IIS to work right now. I still need to address chunked issues, where there is no content length (see http://www.gossamer-threads.com/lists/apache/users/373042) Any comments, sugestions? -Jason --- ./origsrc/git-v2.8.3/http-backend.c 2016-05-18

Possible integer overflow parsing malformed objects in git 2.10.0

Hi, We found a malformed object file that triggers an allocation with a negative size when parsed in git 2.10.0. It can be caused by an integer overflow somewhere, so it is better to verify how the code got such value. It was tested on ArchLinux x86_64. To reproduce, first recompile git with

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Btw, this other test case will trigger a similar issue, but in another line of code: To reproduce: $ git init ; mkdir -p .git/objects/b2 ; printf 'eJwNwoENgDAIBECkDsII5Z8CHagLGPePXu59zjHGRIOZG3OzI/lnRc4KemXDPdYSml6iQ+4ATIZ+nAEK4g==' | base64 -d >

[PATCH 0/2] Locally alias "latin-1" to "ISO-8859-1"

Some systems do not seem to ship "latin-1" as a valid locale, even though they happilly accept more modern official name "ISO-8859-1". Naturally, "iconv -f iso-8859-1" succeeds while "iconv -f latin-1" fails on such a system. We already have in utf8.c to accomodate overly strict iconv_open() that

[PATCH 1/2] utf8: refactor code to decide fallback encoding

The codepath we use to call iconv_open() has a provision to use a fallback encoding when it fails, hoping that "UTF-8" being spelled differently could be the reason why the library function did not like the encoding names we gave it. Essentially, we turn what we have observed to be used as

[PATCH 2/2] utf8: accept "latin-1" as ISO-8859-1

Even though latin-1 is still seen in e-mail headers, some platforms only install ISO-8859-1. "iconv -f ISO-8859-1" succeeds, while "iconv -f latin-1" fails on such a system. Using the same fallback_encoding() mechanism factored out in the previous step, teach ourselves that "ISO-8859-1" has a

Re: [PATCH 0/2] tree-walk improvements

David Turner writes: > Because truncated, to me, means "something that has been cut off". Here, > the recorded length is too short, so it's probably not the case that > something was cut off -- it was never right to begin with. That's perfectly sensible. Thanks.

Re: [PATCH 3/3] add David Turner's Two Sigma address

Sorry for the bad subject line, this is of course v2 of the series. On Mon, 2016-09-26 at 20:11 -0400, David Turner wrote: > From: David Turner > > Signed-off-by: David Turner > --- > .mailmap | 1 + > 1 file changed, 1 insertion(+) > > diff --git

[PATCH 3/3] add David Turner's Two Sigma address

From: David Turner Signed-off-by: David Turner --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index 9441a54..9cc33e9 100644 --- a/.mailmap +++ b/.mailmap @@ -48,6 +48,7 @@ David KÃ¥gedal

[PATCH 1/3] tree-walk: be more specific about corrupt tree errors

From: Jeff King When the tree-walker runs into an error, it just calls die(), and the message is always "corrupt tree file". However, we are actually covering several cases here; let's give the user a hint about what happened. Let's also avoid using the word "corrupt", which

[PATCH 2/3] fsck: handle bad trees like other errors

Instead of dying when fsck hits a malformed tree object, log the error like any other and continue. Now fsck can tell the user which tree is bad, too. Signed-off-by: David Turner --- fsck.c | 18 +++-- t/t1450-fsck.sh

[PATCH 4/4 v4] ls-files: add pathspec matching for submodules

Pathspecs can be a bit tricky when trying to apply them to submodules. The main challenge is that the pathspecs will be with respect to the superproject and not with respect to paths in the submodule. The approach this patch takes is to pass in the identical pathspec from the superproject to the

[PATCH 3/4 v4] ls-files: pass through safe options for --recurse-submodules

Pass through some known-safe options when recursing into submodules. (--cached, --stage, -v, -t, -z, --debug, --eol) Signed-off-by: Brandon Williams --- builtin/ls-files.c | 34 ++ t/t3007-ls-files-recurse-submodules.sh | 17

[PATCH 2/4 v4] ls-files: optionally recurse into submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Use top-level --submodule_prefix option to pass a path to the submodule which it can use to prepend to

[PATCH 1/4 v4] submodules: make submodule-prefix option

Add a submodule-prefix environment variable 'GIT_INTERNAL_SUBMODULE_PREFIX' which can be used by commands which have --recurse-submodule options to give context to submodules about how they were invoked. This option is only allowed for builtins which have submodule support. Signed-off-by:

[PATCH 0/4 v4] recursive support for ls-files

A couple things have changed in v4: - Restructured the patch series to prevent a breakage mid-way. - Added an additional patch in the middle to pass through safe options. This way the series is structured in a more coherent manor. - Added --submodule-prefix to top-level git.c Hopefully this

[PATCH v2 5/5] builtin/tag: add --format argument for tag -v

From: Lukas P Adding --format to git tag -v mutes the default output of the GPG verification and instead prints the formatted tag object. This allows callers to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG verification.

[PATCH v2 4/5] builtin/verify-tag: add --format to verify-tag

From: Santiago Torres Callers of verify-tag may want to cross-check the tagname from refs/tags with the tagname from the tag object header upon GPG verification. This is to avoid tag refs that point to an incorrect object. Add a --format parameter to git verify-tag to print

[PATCH v2 0/5] Add --format to tag verification

From: Santiago Torres This is the second iteration of [1], and as a result of the discussion in [2]. In this re-roll we: * Dropped the commit to move the format string parameter to a global variable on builtin/tag. We had to change the signature of for_each_name_fn to do

[PATCH v2 3/5] tag: add format specifier to gpg_verify_tag

From: Lukas P Calling functions for gpg_verify_tag() may desire to print relevant information about the header for further verification. Add an optional format argument to print any desired information after GPG verification. Signed-off-by: Lukas P

[PATCH v2 1/5] gpg-interface, tag: add GPG_VERIFY_QUIET flag

From: Lukas P Functions that print git object information may require that the gpg-interface functions be silent. Add GPG_VERIFY_QUIET flag and prevent print_signature_buffer from being called if flag is set. Signed-off-by: Lukas P ---

[PATCH v2 2/5] ref-filter: add function to print single ref_array_item

From: Lukas P ref-filter functions are useful for printing git object information using a format specifier. However, some other modules may not want to use this functionality on a ref-array but only print a single item. Expose a format_ref function to create, pretty

Re: [PATCH v8 11/11] convert: add filter..process option

Part first of the review of 11/11. W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > From: Lars Schneider > > Git's clean/smudge mechanism invokes an external filter process for > every single blob that is affected by a filter. If Git filters a lot of >

Re: [PATCH v3 2/2] mailinfo: unescape quoted-pair in header fields

Kevin Daudt writes: > On Mon, Sep 26, 2016 at 12:26:13PM -0700, Junio C Hamano wrote: >> Junio C Hamano writes: >> >> > Don't these also need to be downcased if you prefer $data over >> > $DATA, though? >> >> For now, I'll queue a SQUASH??? that reverts

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

> > By the way, 7dce19d3 is interesting in another way and worth > > studying in that it adds --submodule-prefix ;-) It may be something > > we want to consider consolidating with what Brandon has been working > > on. > > That's why Brandon is cc'd now. :) Interesting. Once we get something we

A couple of bugs / things TODO I encountered

I have these on my TODO list to look at at some point, but who knows when, meanwhile I thought I'd send them to the list if anyone's interested or wants to comment on them. = Inconsistent regexp usage: If you supply --perl-regexp to git-log it only applies to --grep. The documentation says

Re: [RFC PATCH v4] revision: new rev^-n shorthand for rev^n..rev

Vegard Nossum writes: > +test_expect_success 'rev-parse merge^-0' ' > + test_must_fail git rev-parse merge^-0 > +' > + > +test_expect_success 'rev-parse merge^-3' ' > + test_must_fail git rev-parse merge^-3 > +' > + > +test_expect_success 'rev-parse merge^-^' '

Re: git 2.9.2: is RUNTIME_PREFIX supposed to work?

On Mon, Sep 26, 2016 at 2:32 PM, Paul Smith wrote: > Hi all. I'm trying to create a relocatable installation of Git 2.9.2, > so I can copy it anywhere and it continues to run without any problem. > This is on GNU/Linux systems, FWIW. I had an impression that the setting

Re: [RFC PATCH v4] revision: new rev^-n shorthand for rev^n..rev

Junio C Hamano writes: > Micronit. When splitting "for (init; fini; cont)" into multiple > lines, it is often easier to read to make that into three lines: > > for (parent_number = 1, parents = commit->parents; >parents; >parents = parents->next,

Re: [PATCH] git-gui: Do not reset author details on amend

Orgad Shaneh writes: > On Sun, Jul 10, 2016 at 7:36 AM, Orgad Shaneh wrote: > >> On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh wrote: >>> ping? >>> >> It's been over 2 months. Can anyone please review and merge it? >> > 4.5 months and

git 2.9.2: is RUNTIME_PREFIX supposed to work?

Hi all.  I'm trying to create a relocatable installation of Git 2.9.2, so I can copy it anywhere and it continues to run without any problem. This is on GNU/Linux systems, FWIW. Looking through the code (for some other reason) I discovered the RUNTIME_PREFIX setting which appears to attempt to

Re: [RFC PATCH v4] revision: new rev^-n shorthand for rev^n..rev

Vegard Nossum writes: > I often use rev^..rev to get all the commits in the branch that was merged > in by the merge commit 'rev' (including the merge itself). To save typing > (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name) > we can make rev^-

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

On Mon, Sep 26, 2016 at 1:54 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> After a bit more research, I think 8f0700dd33f (fetch/pull: Add the >> 'on-demand' value to the --recurse-submodules option) is the culprit, >> where this patch should have

Re: [PATCH 0/2] tree-walk improvements

David Turner writes: > Hopefully the encoding works correctly on these patches. If not, you > can fetch from > https://github.com/novalis/git/ > on branch dturner/bad-trees This does not test cleanly here, unfortunately. Specifically, tests 30 and 31 t1007 do fine with 1/2

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

Stefan Beller writes: > After a bit more research, I think 8f0700dd33f (fetch/pull: Add the > 'on-demand' value to the --recurse-submodules option) is the culprit, > where this patch should have been squashed into, as that made the > both locations word for word equal. Hmph,

[RFC PATCH v4] revision: new rev^-n shorthand for rev^n..rev

I often use rev^..rev to get all the commits in the branch that was merged in by the merge commit 'rev' (including the merge itself). To save typing (or copy-pasting, if the rev is long -- like a full SHA-1 or branch name) we can make rev^- a shorthand for that. The existing syntax rev^! seems

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

On Mon, Sep 26, 2016 at 1:29 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> Currently the section about recursing into submodules is repeated in >> git-pull word for word as it is in fetch-options. >> >> Don't repeat ourselves here and include the

Re: [PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

Stefan Beller writes: > Currently the section about recursing into submodules is repeated in > git-pull word for word as it is in fetch-options. > > Don't repeat ourselves here and include the --recurse-submodules via > fetch options. > > As a bonus expose the --jobs

Re: [PATCH v8 07/11] pkt-line: add functions to read/write flush terminated packet streams

On 25 Sep 2016, at 15:46, Jakub Narębski wrote: > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> +{ >> +static char buf[PKTLINE_DATA_MAXLEN]; > > Sidenote: we have LARGE_PACKET_MAX (used in previous

Re: [PATCH 0/2] tree-walk improvements

On Mon, 2016-09-26 at 12:43 -0700, Junio C Hamano wrote: > David Turner writes: > > > The first patch is a re-roll of Peff's patch from 2014 -- here's > > the archive message: > > > >

Re: [PATCH 2/2] fsck: handle bad trees like other errors

Junio C Hamano writes: > To prevent further headaches in this directory, can we have > .gitattributes that tells us that everything in there are binary > files? Something like the attached. > > The other object was transferred as a binary patch, but I have no > faith in what

Re: [PATCH 2/2] fsck: handle bad trees like other errors

David Turner writes: > From: David Turner > > Instead of dying when fsck hits a malformed tree object, log the error > like any other and continue. Now fsck can tell the user which tree is > bad, too. > > Signed-off-by: David Turner

Re: [PATCH] git-gui: Do not reset author details on amend

4.5 months and counting... :( - Orgad On Sun, Jul 10, 2016 at 7:36 AM, Orgad Shaneh wrote: > It's been over 2 months. Can anyone please review and merge it? > > Thanks. > - Orgad > > On Wed, May 18, 2016 at 9:12 AM, Orgad Shaneh wrote: >> ping? >> >> On Thu,

Re: [PATCH 2/2] fsck: handle bad trees like other errors

David Turner writes: > @@ -535,7 +536,10 @@ static int fsck_tree(struct tree *item, struct > fsck_options *options) > unsigned o_mode; > const char *o_name; > > - init_tree_desc(, item->buffer, item->size); > + if (init_tree_desc_gently(, item->buffer,

Re: [PATCH v3 2/2] mailinfo: unescape quoted-pair in header fields

On Mon, Sep 26, 2016 at 12:26:13PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > Don't these also need to be downcased if you prefer $data over > > $DATA, though? > > For now, I'll queue a SQUASH??? that reverts s/DATA/data/ you did to > 1/2 between your 1/2 and

Re: [PATCH 0/2] tree-walk improvements

David Turner writes: > The first patch is a re-roll of Peff's patch from 2014 -- here's > the archive message: > > http://git.661346.n2.nabble.com/PATCH-tree-walk-be-more-specific-about-corrupt-tree-errors-td7603558.html > > Not sure why this wasn't applied then, but I

Re: [PATCH 0/2] tree-walk improvements

On Mon, Sep 26, 2016 at 12:32 PM, David Turner wrote: > The first patch is a re-roll of Peff's patch from 2014 -- here's > the archive message: > > http://git.661346.n2.nabble.com/PATCH-tree-walk-be-more-specific-about-corrupt-tree-errors-td7603558.html > > Not sure why this

[PATCH] Documentation/fetch-options: emit recurse-submodules, jobs unconditionally

Currently the section about recursing into submodules is repeated in git-pull word for word as it is in fetch-options. Don't repeat ourselves here and include the --recurse-submodules via fetch options. As a bonus expose the --jobs parameter in git-pull as well as that is declared as a

[PATCH 0/2] tree-walk improvements

The first patch is a re-roll of Peff's patch from 2014 -- here's the archive message: http://git.661346.n2.nabble.com/PATCH-tree-walk-be-more-specific-about-corrupt-tree-errors-td7603558.html Not sure why this wasn't applied then, but I thought it looked pretty good, so I added a few tests.

[PATCH 2/2] fsck: handle bad trees like other errors

From: David Turner Instead of dying when fsck hits a malformed tree object, log the error like any other and continue. Now fsck can tell the user which tree is bad, too. Signed-off-by: David Turner --- fsck.c

[PATCH 1/2] tree-walk: be more specific about corrupt tree errors

From: Jeff King When the tree-walker runs into an error, it just calls die(), and the message is always "corrupt tree file". However, we are actually covering several cases here; let's give the user a hint about what happened. Let's also avoid using the word "corrupt", which

Re: [PATCH v8 06/11] pkt-line: add packet_write_gently()

On 25 Sep 2016, at 13:26, Jakub Narębski wrote: > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> ... >> >> +static int packet_write_gently(const int fd_out, const char *buf, size_t >> size) > > I'm not sure

Re: [PATCH v3 2/2] mailinfo: unescape quoted-pair in header fields

Junio C Hamano writes: > Don't these also need to be downcased if you prefer $data over > $DATA, though? For now, I'll queue a SQUASH??? that reverts s/DATA/data/ you did to 1/2 between your 1/2 and 2/2. Thanks.

Re: [PATCH v3 2/2] mailinfo: unescape quoted-pair in header fields

Kevin Daudt writes: > rfc2822 has provisions for quoted strings and comments in structured header > fields, but also allows for escaping these with so-called quoted-pairs. > > The only thing git currently does is removing exterior quotes, but > quotes within are left alone. > >

Re: What's cooking in git.git (Sep 2016, #07; Fri, 23)

Johannes Schindelin writes: > Also, I found https://tinyurl.com/gitCal very convenient a URL to point > to, do you plan to update that for v2.11.0? Thanks for reminding. I've barely had enough bandwidth to keep up with the list traffic for the past few weeks, and

Re: [PATCH v3 1/2] t5100-mailinfo: replace common path prefix with variable

Kevin Daudt writes: > Many tests need to store data in a file, and repeat the same pattern to > refer to that path: > > "$TEST_DIRECTORY"/t5100/ > > Create a variable that contains this path, and use that instead. > > Signed-off-by: Kevin Daudt >

Re: [PATCH v8 02/11] pkt-line: extract set_packet_header()

On 24 Sep 2016, at 23:22, Jakub Narębski wrote: > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > >> From: Lars Schneider >> >> Subject: [PATCH v8 02/11] pkt-line: extract set_packet_header() >> >> set_packet_header() converts an

Re: [PATCH v8 01/11] pkt-line: rename packet_write() to packet_write_fmt()

On 24 Sep 2016, at 23:14, Jakub Narębski wrote: > Hello Lars, > > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: > >> From: Lars Schneider >> >> packet_write() should be called packet_write_fmt() as the string >> parameter can be

Re: [PATCH 0/3] recursive support for ls-files

Brandon Williams writes: > or something along those lines. That way we only need to add the flag > to each command as we go ... Sounds good. Thanks.

Re: [PATCH 0/3] recursive support for ls-files

On 09/26, Junio C Hamano wrote: > Brandon Williams writes: > > > In a previous email you mentioned that this feature should be completely > > hidden from users, which is why I removed the command line option for > > this latest series. > > I may have said something like that;

Re: [PATCH v2 04/11] i18n: add--interactive: mark plural strings

Vasco Almeida writes: >> > + } elsif ($did eq 'reversed') { >> > + printf(Q__("reversed one path\n", "reversed %d paths\n", > > This should be 'reverted' not 'reversed'. I'll mark v2 of this topic "not to be merged yet"; please send in a corrected version 3

Re: [PATCH 0/3] recursive support for ls-files

Brandon Williams writes: > In a previous email you mentioned that this feature should be completely > hidden from users, which is why I removed the command line option for > this latest series. I may have said something like that; I do not recall, though, so a more accurate

Re: [PATCH v2 04/11] i18n: add--interactive: mark plural strings

A Qua, 31-08-2016 às 12:31 +, Vasco Almeida escreveu: > Mark plural strings for translation.  Unfold each action case in one > entire sentence. > > Pass new keyword for xgettext to extract. > > Update test to include new subrotine Q__() for plural strings handling. > > > Signed-off-by:

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Junio C Hamano writes: > I am inclined to say that it has no security implications. You have > to be able to write a bogus loose object in an object store you > already have write access to in the first place, in order to cause > this ... Note that you could social-engineer

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Gustavo Grieco writes: > Fair enough. We are testing our tool to try to find > bugs/vulnerabilities in several git implementations. I will report > here my results if i can find some other memory issue in this git > client. Thanks. With or without security implications,

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Fair enough. We are testing our tool to try to find bugs/vulnerabilities in several git implementations. I will report here my results if i can find some other memory issue in this git client. - Original Message - > Gustavo Grieco writes: > > > Now that the

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Gustavo Grieco writes: > Now that the cause of this issue is identified, i would like to > know if there is an impact in the security, so i can request a CVE > if necessary. I am inclined to say that it has no security implications. You have to be able to write a bogus

Re: [PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

Jeff King writes: >> Other than your reinvention of HAS_MULTI_BITS(), which has been with >> us since db7244bd ("parse-options new features.", 2007-11-07), this >> looks like a reasonable thing to do. > > Heh, I _thought_ we had something like that but couldn't find it. I >

Re: Stack read out-of-bounds in parse_sha1_header_extended using git 2.10.0

Hello, Now that the cause of this issue is identified, i would like to know if there is an impact in the security, so i can request a CVE if necessary. Thanks!

Re: [PATCH] unpack_sha1_header(): detect malformed object header

On Mon, Sep 26, 2016 at 10:33:57AM -0700, Junio C Hamano wrote: > -- >8 -- > From: Junio C Hamano > Date: Mon, 26 Sep 2016 09:23:41 -0700 > Subject: [PATCH 1/2] streaming: make sure to notice corrupt object > > The streaming read interface from a loose object called >

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

Jeff King writes: > Since it's attached to an error path, I'm guessing nobody will be too > upset about it, so my inclination was to wait and let somebody add the > conditional advice code if they're bothered. Fair enough. At that point of getting an error message, the only

Re: [PATCH] unpack_sha1_header(): detect malformed object header

Jeff King writes: >> diff --git a/streaming.c b/streaming.c >> index 811fcc2..884a8f1 100644 >> --- a/streaming.c >> +++ b/streaming.c >> @@ -347,7 +347,8 @@ static open_method_decl(loose) >> return -1; >> } >> >> -parse_sha1_header(st->u.loose.hdr, >size);

Re: [PATCH] unpack_sha1_header(): detect malformed object header

On Mon, Sep 26, 2016 at 10:34:32AM -0700, Junio C Hamano wrote: > And the second one, that no longer checks SP in unpacker, looks like > this. This looks good from a cursory read (but I am about to go to sleep, so might be a bit less careful than usual :) ). -Peff

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Mon, Sep 26, 2016 at 10:30:48AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > We also restrict the list to those that match any > > disambiguation hint. E.g.: > > > > $ git rev-parse b2e1:foo > > error: short SHA1 b2e1 is ambiguous > > hint: The candidates are:

Re: [PATCH] unpack_sha1_header(): detect malformed object header

And the second one, that no longer checks SP in unpacker, looks like this. -- >8 -- Subject: [PATCH] unpack_sha1_header(): detect malformed object header When opening a loose object file, we often do this sequence: - prepare a short buffer for the object header (on stack) - call

Re: [PATCH] unpack_sha1_header(): detect malformed object header

Junio C Hamano writes: > Good that your attempt to signature-changing change caught it. I'll > take a further look. So here are two patch series. The first one makes sure all callers of parse_sha1_header() check the returned status. -- >8 -- From: Junio C Hamano

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

Jeff King writes: > We also restrict the list to those that match any > disambiguation hint. E.g.: > > $ git rev-parse b2e1:foo > error: short SHA1 b2e1 is ambiguous > hint: The candidates are: > hint: b2e1196 tag v2.8.0-rc1 > hint: b2e11d1 tree > hint: b2e1632

Re: [PATCH 06/10] get_short_sha1: NUL-terminate hex prefix

On Mon, Sep 26, 2016 at 10:10:46AM -0700, Junio C Hamano wrote: > > struct disambiguate_state { > > int len; /* length of prefix in hex chars */ > > - char hex_pfx[GIT_SHA1_HEXSZ]; > > + char hex_pfx[GIT_SHA1_HEXSZ + 1]; > > unsigned char bin_pfx[GIT_SHA1_RAWSZ]; > > > >

Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish

On Mon, Sep 26, 2016 at 09:55:20AM -0700, Junio C Hamano wrote: > > Instead, we can use parse_object(). Note that this is the > > same fix done by 94d75d1 (get_short_sha1(): correctly > > disambiguate type-limited abbreviation, 2013-07-01), but > > that commit fixed only the committish

Re: [PATCH] git-gui: stop using deprecated merge syntax

On Sun, Sep 25, 2016 at 11:39 AM, Junio C Hamano wrote: > Johannes Sixt writes: > >> Am 24.09.2016 um 13:30 schrieb René Scharfe: >>> Starting with v2.5.0 git merge can handle FETCH_HEAD internally and >>> warns when it's called like 'git merge HEAD ' because

Re: [PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

On Mon, Sep 26, 2016 at 09:37:10AM -0700, Junio C Hamano wrote: > > We can do the check easily with some bit-twiddling, and as a > > bonus, the bit-mask of disambiguators will come in handy in > > a future patch. > > > > Signed-off-by: Jeff King > > --- > > Other than your

Re: Request: Extra case for %G? format

Michael J Gruber writes: >> Then currently %G? results in `N', the same as an unsigned commit. >> >> In this case, could %G? please result in a new character? Perhaps `M' >> for "missing public key"? > > Yes, and no. > > Really, there are many different reasons why a

Re: [PATCH 06/10] get_short_sha1: NUL-terminate hex prefix

Jeff King writes: > We store the hex prefix in a 40-byte buffer with the prefix > itself followed by 40-minus-len "x" characters. These x's > serve no purpose, and the lack of NUL termination makes the > prefix string annoying to use. Let's just terminate it. > Note that this is

Re: [PATCH 0/3] recursive support for ls-files

On 09/25, Junio C Hamano wrote: > Brandon Williams writes: > > > On 09/25, Jeff King wrote: > >> On Fri, Sep 23, 2016 at 05:13:31PM -0700, Brandon Williams wrote: > >> > >> > After looking at the feedback I rerolled a few things, in particular the > >> > --submodule_prefix

Re: [PATCH 04/10] get_short_sha1: peel tags when looking for treeish

Jeff King writes: > The treeish disambiguation function tries to peel tags, but > it does so by calling: > > deref_tag(lookup_object(sha1), ...); > > This will only work if we have previously looked at the tag > and created a "struct tag" for it. Since parsing revision >

Re: [PATCH 01/10] get_sha1: detect buggy calls with multiple disambiguators

Jeff King writes: > The get_sha1() family of functions takes a flags field, but > some of the flags are mutually exclusive. In particular, we > can only handle one disambiguating function, and the flags > quietly override each other. Let's instead detect these as > programming

Re: [PATCH 10/10] get_short_sha1: list ambiguous objects on error

On Mon, Sep 26, 2016 at 5:00 AM, Jeff King wrote: > > This patch teaches get_short_sha1() to list the sha1s of the > objects it found, along with a few bits of information that > may help the user decide which one they meant. This looks very good to me, but I wonder if it couldn't

Re: [PATCH v8 03/11] run-command: move check_pipe() from write_or_die to run_command

On 26 September 2016 at 18:13, Lars Schneider wrote: >> On 25 Sep 2016, at 00:12, Jakub Narębski wrote: >> W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >>> From: Lars Schneider >>> >>> Move check_pipe() to

Re: [PATCH] unpack_sha1_header(): detect malformed object header

Jeff King writes: > This part I don't understand, though. We clearly need to look for the > NUL. But why do we need to look for the space? The loop in > parse_sha1_header() can easily detect this as it looks for the end of > the type name (and if it hits the end-of-string, can

Re: [PATCH v8 03/11] run-command: move check_pipe() from write_or_die to run_command

> On 25 Sep 2016, at 00:12, Jakub Narębski wrote: > > W dniu 20.09.2016 o 21:02, larsxschnei...@gmail.com pisze: >> From: Lars Schneider >> >> Move check_pipe() to run_command and make it public. This is necessary >> to call the function from

Re: BUG: Git blame provides incorrect previous commit if the line is uncommitted

Eric Amodio writes: > This is the first time I've reported a bug with Git so please forgive > me if this isn't the right place, format, etc. > > If git blame --porcelain (or --line-porcelain or --incremental) is run > on a file that has uncommitted changes any uncommitted

  1   2   >