From: Michael Haggerty <mhagger@alum.mit.edu>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>,
"Junio C Hamano" <gitster@pobox.com>
Cc: Eric Sunshine <sunshine@sunshineco.com>,
Ronnie Sahlberg <sahlberg@google.com>,
git@vger.kernel.org, Michael Haggerty <mhagger@alum.mit.edu>
Subject: [PATCH v2 08/11] resolve_gitlink_ref_recursive(): drop arbitrary refname length limit
Date: Wed, 15 Oct 2014 17:06:20 +0200 [thread overview]
Message-ID: <1413385583-4872-9-git-send-email-mhagger@alum.mit.edu> (raw)
In-Reply-To: <1413385583-4872-1-git-send-email-mhagger@alum.mit.edu>
This limit was added in
0ebde32 (Add 'resolve_gitlink_ref()' helper function - 2007-04-09)
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
---
Theoretically, somebody else might be relying on
resolve_gitlink_ref_recursive() to fail for too-long reference names
to prevent path.c's pitiful error handling from returning "/bad-path/"
and causing a nonsensical file lookup. I doubt it, but if somebody is
worried about it we could leave out this patch and instead build the
MAXREFLEN check into parse_ref().
Long-term, I think we should fix up path.c to remove its PATH_MAX
limits. I've started working on that.
refs.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/refs.c b/refs.c
index 9f2a0f8..e1aa6a4 100644
--- a/refs.c
+++ b/refs.c
@@ -1279,7 +1279,6 @@ static struct ref_dir *get_loose_refs(struct ref_cache *refs)
/* We allow "recursive" symbolic refs. Only within reason, though */
#define MAXDEPTH 5
-#define MAXREFLEN (1024)
/*
* Called by resolve_gitlink_ref_recursive() after it failed to read
@@ -1308,7 +1307,7 @@ static int resolve_gitlink_ref_recursive(struct ref_cache *refs,
char buffer[128], *p;
char *path;
- if (recursion > MAXDEPTH || strlen(refname) > MAXREFLEN)
+ if (recursion > MAXDEPTH)
return -1;
path = *refs->name
? git_path_submodule(refs->name, "%s", refname)
--
2.1.1
next prev parent reply other threads:[~2014-10-15 15:06 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-10-15 15:06 [PATCH v2 00/11] Consolidate ref parsing code Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 01/11] strbuf_read_file(): preserve errno on failure Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 02/11] handle_missing_loose_ref(): return an int Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 03/11] resolve_ref_unsafe(): reverse the logic of the symref conditional Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 04/11] resolve_ref_unsafe(): use skip_prefix() to skip over "ref:" Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 05/11] refs.c: refactor resolve_ref_unsafe() to use strbuf internally Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 06/11] refs.c: move ref parsing code out of resolve_ref() Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 07/11] handle_missing_loose_ref(): inline function Michael Haggerty
2014-10-15 15:06 ` Michael Haggerty [this message]
2014-10-15 15:06 ` [PATCH v2 09/11] refs.c: rewrite resolve_gitlink_ref() to use parse_ref() Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 10/11] resove_gitlink_packed_ref(): inline function Michael Haggerty
2014-10-15 15:06 ` [PATCH v2 11/11] resolve_gitlink_ref(): remove redundant test Michael Haggerty
2014-10-16 20:47 ` [PATCH v2 00/11] Consolidate ref parsing code Junio C Hamano
2014-10-16 21:51 ` Junio C Hamano
2014-10-16 23:23 ` Michael Haggerty
2014-10-16 23:53 ` Duy Nguyen
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=1413385583-4872-9-git-send-email-mhagger@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=pclouds@gmail.com \
--cc=sahlberg@google.com \
--cc=sunshine@sunshineco.com \
/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).