From: Joachim Durchholz <jo@durchholz.org>
To: git@vger.kernel.org
Subject: Re: [PATCH] submodule: prevent backslash expantion in submodule names
Date: Sat, 8 Apr 2017 22:32:41 +0200 [thread overview]
Message-ID: <d8ef00f6-4ec0-dfcb-dc49-71f27538eb2f@durchholz.org> (raw)
In-Reply-To: <20170408105901.2osi2zadboqxhf34@sigill.intra.peff.net>
Am 08.04.2017 um 12:59 schrieb Jeff King:
> The reason I mentioned escaping earlier is I wondered what would happen
> when the submodule starts with a double-quote, or has a newline in the
> name.
I have tested newlines within the name, these work fine.
I also tested double and single quotes within the name, but not at
beginning or end.
> So I think your patch is fine there. But it does raise a few concerns.
> It looks like git-submodule does not cope well with exotic filenames:
>
> $ git submodule add /some/repo "$(printf 'sub with\nnewline')"
> Cloning into '/home/peff/tmp/sub with
> newline'...
> done.
> error: invalid key (newline): submodule.sub with
> newline.url
> error: invalid key (newline): submodule.sub with
> newline.path
> Failed to register submodule 'sub with
> newline'
Strange. I'm running essentially the same kind of request, and things
work fine.
Might be due to me using Python3 instead of bash, or maybe due to
different versions of git.
If anybody is interested, I can publish my test code on github, it was
scheduled to land there anyway.
> I'm not too worried about that. It's a nonsense request, and our config
> format has no syntactic mechanism to represent that key.
Oh. I've been thinking that the quoted format is exactly for that kind
of stuff.
Though it might be prone to eol conversion if a submodule name contains
crlf sequences.
Also, funny behavour. Experience has taught me that funny behaviour, if
it isn't exploitable today, may combine with some new funny behaviour in
a future version of the same software. So I'm worried even with that.
This is starting to look like a can of worms to me... one way to "close
the lid" would be if git
* defined what's a valid submodule name,
* rejected invalid submodule names, and
* documented validity rules in the git-submodule docs.
YMMV, just my 2 cents :-)
Regards,
Jo
next prev parent reply other threads:[~2017-04-08 20:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-04-07 6:12 problem with backslash in directory name Joachim Durchholz
2017-04-07 6:30 ` Jeff King
2017-04-07 8:24 ` Joachim Durchholz
2017-04-07 8:40 ` Joachim Durchholz
2017-04-07 16:53 ` Brandon Williams
2017-04-07 16:55 ` Stefan Beller
2017-04-07 17:23 ` [PATCH] submodule: prevent backslash expantion in submodule names Brandon Williams
2017-04-07 17:35 ` Joachim Durchholz
2017-04-08 10:59 ` Jeff King
2017-04-08 20:32 ` Joachim Durchholz [this message]
2017-04-17 3:09 ` Junio C Hamano
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d8ef00f6-4ec0-dfcb-dc49-71f27538eb2f@durchholz.org \
--to=jo@durchholz.org \
--cc=git@vger.kernel.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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).