git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jeff King <peff@peff.net>
To: git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
	Jonathan Nieder <jrnieder@gmail.com>,
	"Shawn O. Pearce" <spearce@spearce.org>
Subject: [PATCH v3 01/19] upload-pack: use get_sha1_hex to parse "shallow" lines
Date: Wed, 20 Feb 2013 14:53:33 -0500	[thread overview]
Message-ID: <20130220195333.GA25647@sigill.intra.peff.net> (raw)
In-Reply-To: <20130220195147.GA25332@sigill.intra.peff.net>

When we receive a line like "shallow <sha1>" from the
client, we feed the <sha1> part to get_sha1. This is a
mistake, as the argument on a shallow line is defined by
Documentation/technical/pack-protocol.txt to contain an
"obj-id".  This is never defined in the BNF, but it is clear
from the text and from the other uses that it is meant to be
a hex sha1, not an arbitrary identifier (and that is what
fetch-pack has always sent).

We should be using get_sha1_hex instead, which doesn't allow
the client to request arbitrary junk like "HEAD@{yesterday}".
Because this is just marking shallow objects, the client
couldn't actually do anything interesting (like fetching
objects from unreachable reflog entries), but we should keep
our parsing tight to be on the safe side.

Because get_sha1 is for the most part a superset of
get_sha1_hex, in theory the only behavior change should be
disallowing non-hex object references. However, there is
one interesting exception: get_sha1 will only parse
a 40-character hex sha1 if the string has exactly 40
characters, whereas get_sha1_hex will just eat the first 40
characters, leaving the rest. That means that current
versions of git-upload-pack will not accept a "shallow"
packet that has a trailing newline, even though the protocol
documentation is clear that newlines are allowed (even
encouraged) in non-binary parts of the protocol.

This never mattered in practice, though, because fetch-pack,
contrary to the protocol documentation, does not include a
newline in its shallow lines. JGit follows its lead (though
it correctly is strict on the parsing end about wanting a
hex object id).

We do not adjust fetch-pack to send newlines here, as it
would break communication with older versions of git (and
there is no actual benefit to doing so, except for
consistency with other parts of the protocol).

Signed-off-by: Jeff King <peff@peff.net>
---
I couldn't trigger anything interestingly malicious from this, but I
didn't look very hard. Maybe somebody who knows the shallow protocol
better could think of something clever (not that it matters much).

 upload-pack.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/upload-pack.c b/upload-pack.c
index 30146a0..b058e8d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -596,7 +596,7 @@ static void receive_needs(void)
 		if (!prefixcmp(line, "shallow ")) {
 			unsigned char sha1[20];
 			struct object *object;
-			if (get_sha1(line + 8, sha1))
+			if (get_sha1_hex(line + 8, sha1))
 				die("invalid shallow line: %s", line);
 			object = parse_object(sha1);
 			if (!object)
-- 
1.8.2.rc0.9.g352092c

  reply	other threads:[~2013-02-20 19:54 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-02-20 19:51 [PATCHv3 0/19] pkt-line cleanups and fixes Jeff King
2013-02-20 19:53 ` Jeff King [this message]
2013-02-20 19:54 ` [PATCH v3 02/19] upload-pack: do not add duplicate objects to shallow list Jeff King
2013-02-20 19:55 ` [PATCH v3 03/19] upload-pack: remove packet debugging harness Jeff King
2013-02-20 20:00 ` [PATCH v3 04/19] fetch-pack: fix out-of-bounds buffer offset in get_ack Jeff King
2013-02-20 20:00 ` [PATCH v3 05/19] send-pack: prefer prefixcmp over memcmp in receive_status Jeff King
2013-02-20 20:00 ` [PATCH v3 06/19] upload-archive: do not copy repo name Jeff King
2013-02-20 20:01 ` [PATCH v3 07/19] upload-archive: use argv_array to store client arguments Jeff King
2013-02-20 20:01 ` [PATCH v3 08/19] write_or_die: raise SIGPIPE when we get EPIPE Jeff King
2013-02-20 21:51   ` Jonathan Nieder
2013-02-20 21:58     ` Jeff King
2013-02-20 22:01       ` Jonathan Nieder
2013-02-20 22:03         ` Jeff King
2013-02-20 22:06           ` Jonathan Nieder
2013-02-20 22:12             ` Jeff King
2013-02-20 22:19               ` Junio C Hamano
2014-03-28  8:35   ` [BUG] MSVC: error box when interrupting `gitlog` by quitting less Marat Radchenko
2014-03-28  9:14     ` Marat Radchenko
2014-03-28  9:44       ` Jeff King
2014-03-28 10:07         ` Marat Radchenko
2014-03-28 10:19           ` Jeff King
2014-03-28 10:28           ` Johannes Sixt
2014-03-28 11:19             ` [PATCH] MSVC: link in invalidcontinue.obj for better POSIX compatibility Marat Radchenko
2014-03-28 18:27               ` Junio C Hamano
2014-03-28 18:46                 ` Marat Radchenko
2014-03-28 19:06                 ` Junio C Hamano
2014-03-28 20:08                   ` [PATCH v2] " Marat Radchenko
2014-03-28 20:35                     ` Junio C Hamano
2013-02-20 20:01 ` [PATCH v3 09/19] pkt-line: move a misplaced comment Jeff King
2013-02-20 20:01 ` [PATCH v3 10/19] pkt-line: drop safe_write function Jeff King
2013-02-20 20:02 ` [PATCH v3 11/19] pkt-line: provide a generic reading function with options Jeff King
2013-02-20 20:02 ` [PATCH v3 12/19] pkt-line: teach packet_read_line to chomp newlines Jeff King
2013-02-20 20:02 ` [PATCH v3 13/19] pkt-line: move LARGE_PACKET_MAX definition from sideband Jeff King
2013-02-20 20:02 ` [PATCH v3 14/19] pkt-line: provide a LARGE_PACKET_MAX static buffer Jeff King
2013-02-20 20:04 ` [PATCH v3 15/19] pkt-line: share buffer/descriptor reading implementation Jeff King
2013-02-22 11:22   ` Eric Sunshine
2013-02-20 20:06 ` [PATCH v3 16/19] teach get_remote_heads to read from a memory buffer Jeff King
2013-02-20 20:07 ` [PATCH v3 17/19] remote-curl: pass buffer straight to get_remote_heads Jeff King
2013-02-20 20:07 ` [PATCH v3 18/19] remote-curl: move ref-parsing code up in file Jeff King
2013-02-20 20:07 ` [PATCH v3 19/19] remote-curl: always parse incoming refs Jeff King

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130220195333.GA25647@sigill.intra.peff.net \
    --to=peff@peff.net \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jrnieder@gmail.com \
    --cc=spearce@spearce.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).