Skip to content

G
git

李少辉-开发者 / git
与 Fork 源项目一致

从无法访问的项目Fork

通知 2
Star 1
Fork 0
G
git

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 05 11月, 2009 1 次提交
  3. 04 11月, 2009 2 次提交
  5. 02 11月, 2009 2 次提交
  7. 31 10月, 2009 4 次提交
  9. 29 10月, 2009 1 次提交
  11. 28 10月, 2009 4 次提交
  13. 26 10月, 2009 5 次提交
  15. 25 10月, 2009 2 次提交
  17. 24 10月, 2009 5 次提交
  19. 22 10月, 2009 5 次提交
    • J
      Fix incorrect error check while reading deflated pack data · 39eea7bd
      由 Junio C Hamano 提交于 
      The loop in get_size_from_delta() feeds a deflated delta data from the
pack stream _until_ we get inflated result of 20 bytes[*] or we reach the
end of stream.

    Side note. This magic number 20 does not have anything to do with the
    size of the hash we use, but comes from 1a3b55c6 (reduce delta head
    inflated size, 2006-10-18).

The loop reads like this:

    do {
        in = use_pack();
        stream.next_in = in;
        st = git_inflate(&stream, Z_FINISH);
        curpos += stream.next_in - in;
    } while ((st == Z_OK || st == Z_BUF_ERROR) &&
             stream.total_out < sizeof(delta_head));

This git_inflate() can return:

 - Z_STREAM_END, if use_pack() fed it enough input and the delta itself
   was smaller than 20 bytes;

 - Z_OK, when some progress has been made;

 - Z_BUF_ERROR, if no progress is possible, because we either ran out of
   input (due to corrupt pack), or we ran out of output before we saw the
   end of the stream.

The fix b3118bdc (sha1_file: Fix infinite loop when pack is corrupted,
2009-10-14) attempted was against a corruption that appears to be a valid
stream that produces a result larger than the output buffer, but we are
not even trying to read the stream to the end in this loop.  If avail_out
becomes zero, total_out will be the same as sizeof(delta_head) so the loop
will terminate without the "fix".  There is no fix from b3118bdc needed for
this loop, in other words.

The loop in unpack_compressed_entry() is quite a different story.  It
feeds a deflated stream (either delta or base) and allows the stream to
produce output up to what we expect but no more.

    do {
        in = use_pack();
        stream.next_in = in;
        st = git_inflate(&stream, Z_FINISH);
        curpos += stream.next_in - in;
    } while (st == Z_OK || st == Z_BUF_ERROR)

This _does_ risk falling into an endless interation, as we can exhaust
avail_out if the length we expect is smaller than what the stream wants to
produce (due to pack corruption).  In such a case, avail_out will become
zero and inflate() will return Z_BUF_ERROR, while avail_in may (or may
not) be zero.

But this is not a right fix:

    do {
        in = use_pack();
        stream.next_in = in;
        st = git_inflate(&stream, Z_FINISH);
+       if (st == Z_BUF_ERROR && (stream.avail_in || !stream.avail_out)
+               break; /* wants more input??? */
        curpos += stream.next_in - in;
    } while (st == Z_OK || st == Z_BUF_ERROR)

as Z_BUF_ERROR from inflate() may be telling us that avail_in has also run
out before reading the end of stream marker.  In such a case, both avail_in
and avail_out would be zero, and the loop should iterate to allow the end
of stream marker to be seen by inflate from the input stream.

The right fix for this loop is likely to be to increment the initial
avail_out by one (we allocate one extra byte to terminate it with NUL
anyway, so there is no risk to overrun the buffer), and break out if we
see that avail_out has become zero, in order to detect that the stream
wants to produce more than what we expect.  After the loop, we have a
check that exactly tests this condition:

    if ((st != Z_STREAM_END) || stream.total_out != size) {
        free(buffer);
        return NULL;
    }

So here is a patch (without my previous botched attempts) to fix this
issue.  The first hunk reverts the corresponding hunk from b3118bdc, and
the second hunk is the same fix proposed earlier.
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      39eea7bd
    • B
      git-clone.txt: Fix grammar and formatting · 550c66f3
      由 Björn Gustavsson 提交于 
      Add the missing definite article ("the") in several places.

Change "note to..." to "note for...", since "note to" means that
that the note is addressed to someone (source: Google search).

Change "progressbar" to "progress bar" (source: Wikipedia).

Format git commands, options, and file names consistently using
back quotes (i.e. a fixed font in the resulting HTML document).
Signed-off-by: NBjörn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      550c66f3
    • N
      Document `delta` attribute in "git help attributes". · 975457f1
      由 Nasser Grainawi 提交于 
      Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      975457f1
    • J
      Mark files in t/t5100 as UTF-8 · 814a9bfe
      由 Johannes Sixt 提交于 
      This enables gitk to show the patch text with correct glyphs if the locale
is not UTF-8.
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      814a9bfe
    • J
      Remove a left-over file from t/t5100 · 66bcb6a6
      由 Johannes Sixt 提交于 
      This mbox file must have been added by accident in e9fe804a (git-mailinfo:
Fix getting the subject from the in-body [PATCH] line, 2008-07-14).
Signed-off-by: NJohannes Sixt <j6t@kdbg.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      66bcb6a6
  21. 20 10月, 2009 1 次提交
  23. 19 10月, 2009 4 次提交
  25. 17 10月, 2009 3 次提交
  27. 15 10月, 2009 1 次提交
    • S
      sha1_file: Fix infinite loop when pack is corrupted · b3118bdc
      由 Shawn O. Pearce 提交于 
      Some types of corruption to a pack may confuse the deflate stream
which stores an object.  In Andy's reported case a 36 byte region
of the pack was overwritten, leading to what appeared to be a valid
deflate stream that was trying to produce a result larger than our
allocated output buffer could accept.

Z_BUF_ERROR is returned from inflate() if either the input buffer
needs more input bytes, or the output buffer has run out of space.
Previously we only considered the former case, as it meant we needed
to move the stream's input buffer to the next window in the pack.

We now abort the loop if inflate() returns Z_BUF_ERROR without
consuming the entire input buffer it was given, or has filled
the entire output buffer but has not yet returned Z_STREAM_END.
Either state is a clear indicator that this loop is not working
as expected, and should not continue.

This problem cannot occur with loose objects as we open the entire
loose object as a single buffer and treat Z_BUF_ERROR as an error.
Reported-by: NAndy Isaacson <adi@hexapodia.org>
Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
Acked-by: NNicolas Pitre <nico@fluxnic.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>
      b3118bdc