From: Toon Claes <toon@to1.studio>
To: Junio C Hamano <gitster@pobox.com>
Cc: Phillip Wood <phillip.wood123@gmail.com>,
Toon Claes <toon@iotcl.com>,
git@vger.kernel.org
Subject: Re: [PATCH 1/1] cat-file: quote-format name in error when using -z
Date: Mon, 12 Dec 2022 12:34:46 +0100 [thread overview]
Message-ID: <87cz8ohklt.fsf@to1.studio> (raw)
In-Reply-To: <xmqq8rjdv5um.fsf@gitster.g>
Junio C Hamano <gitster@pobox.com> writes:
> Phillip Wood <phillip.wood123@gmail.com> writes:
>
>> Without "-z" you cannot pass object names that contain newlines so not
>> quoting the output does not cause a problem. We could start quoting
>> the object name without "-z" but we'd be changing the output without a
>> huge benefit.
>
> That's fair. The next question is from a devil's advocate:
> is switching to the full cquote the best thing to do?
>
> If we were using the full cquote from the very beginning, of course
> it is, simply because that is what is used in all other places in
> Git. Using the full cquote does mean a LF byte will be protected
> (i.e. instead of shown literally in the middle of other letters
> around LF, "other\nletters around LF" would be shown), but pathnames
> with backslashes and double quotes in them that have been shown
> without problems would be shown differently and will break existing
> parsers, which are written lazily with the assumption that they are
> perfectly happy to be "simple" thans to not having to deal with LF
> (because in their environment a path with LF in it do not matter).
>
> A bit safer thing to do is to replace LF (and not any other bytes
> that would be quoted with full cquote) in the path given in these
> messages with something else (like NUL to truncate the output
> there).
So object name "HEAD:other\nletters around LF" would give the error
message "other missing"? That error message would also occur when the
user does not provide -z. I think that might be confusing.
> As these answers are given in order, the object names are
> not absolutely needed to identify and match up the input and the
> output, and properly written parsers would be prepared to see a
> response with an object name that it did not request and handle it
> sanely, such a change may not break such a parser for a path with
> any byte that are modified with full cquote.
Yes, the answers are returned in order, so personally I don't care too
much about the returned object name format. I even would be fine with a
generic error message that omits the input name, for example "object
missing". As long as it's clear that the requested object is not found.
For your information, there is an extreme edge case a user could fake an
object, and that's what we want to avoid as well. For example the
command (line break included):
printf "aabbccddeeff00112233445566778899aabbccdd blob 26
this object is not" | git cat-file --batch -z
Would print:
aabbccddeeff00112233445566778899aabbccdd blob 26
this object is not missing
This is perfectly valid git-cat-file output. Luckily I don't see any way
how this can be abused. Generally I think it's a good idea to not return
the input as-is in any situation. We could only replace newlines, but
cquoting already sanitizes the input, so why not use that?
> The above is with a devil's adovocate hat on, and I do not care too
> much, as I do not think butchering backslash with full cquote would
> not hurt even existing Windows users (if "HEAD:t\README.txt" named
> the same blob as "HEAD:t/README.txt" on a platform, doubling the
> backslashes in the output would have made quite a lot of damage, but
> I do not think we allow backslashes to name tree paths).
> By the way, there is another use of obj_name in batch_object_write()
> that can show whatever byte in it literally to the output.
Ah thanks! I will include in the next version, when we reach a consensus
on when or what to cquote.
--
Toon
next prev parent reply other threads:[~2022-12-12 12:28 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-09 15:00 [PATCH 0/1] cat-file: quote-format name in error when using -z Toon Claes
2022-12-09 15:00 ` [PATCH 1/1] " Toon Claes
2022-12-09 19:33 ` Phillip Wood
2022-12-09 23:58 ` Junio C Hamano
2022-12-11 16:30 ` Phillip Wood
2022-12-12 0:11 ` Junio C Hamano
2022-12-12 11:34 ` Toon Claes [this message]
2022-12-12 22:09 ` Junio C Hamano
2022-12-13 15:06 ` Phillip Wood
2022-12-14 8:29 ` Junio C Hamano
2022-12-20 5:31 ` Toon Claes
2022-12-20 10:18 ` Phillip Wood
2022-12-21 12:42 ` Toon Claes
2023-01-05 6:24 ` [PATCH v2 0/1] " Toon Claes
2023-01-05 6:24 ` [PATCH v2 1/1] " Toon Claes
2023-01-16 19:07 ` [PATCH v3 0/1] " Toon Claes
2023-01-16 19:07 ` [PATCH v3 1/1] " Toon Claes
2023-01-17 15:24 ` Phillip Wood
2023-03-03 19:17 ` [PATCH v4 0/2] " Toon Claes
2023-03-03 19:17 ` [PATCH v4 1/2] cat-file: extract printing batch error message into function Toon Claes
2023-03-03 20:26 ` Junio C Hamano
2023-03-03 23:14 ` Junio C Hamano
2023-05-10 19:01 ` [PATCH v5 0/1] cat-file: quote-format name in error when using -z Toon Claes
2023-05-10 19:01 ` [PATCH v5 1/1] " Toon Claes
2023-05-10 20:13 ` Junio C Hamano
2023-05-12 8:54 ` Toon Claes
2023-05-12 16:57 ` Junio C Hamano
2023-05-15 8:47 ` Phillip Wood
2023-05-15 17:20 ` Junio C Hamano
2023-06-02 13:29 ` Phillip Wood
2023-03-03 19:17 ` [PATCH v4 2/2] " Toon Claes
2023-03-03 20:14 ` [PATCH v4 0/2] " 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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87cz8ohklt.fsf@to1.studio \
--to=toon@to1.studio \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=phillip.wood123@gmail.com \
--cc=toon@iotcl.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 read-only IMAP folder(s) and NNTP newsgroup(s).