"Ivan Frade via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> From: Ivan Frade <ifrade@xxxxxxxxxx>
>
> In some setups, packfile uris act as bearer token. It is not
> recommended to expose them plainly in logs, although in special
> circunstances (e.g. debug) it makes sense to write them.
>
> Redact the packfile-uri lines by default, unless the GIT_TRACE_REDACT
> variable is set to false. This mimics the redacting of the
> Authorization header in HTTP.
Well explained.
It of course is a different matter if the explained idea is
agreeable, though ;-). Hiding the entire packet, based on the "it
might be in some setups" seems a bit too much.
Is it often the case that the whole URI is sensitive, or perhaps
leading "<scheme>://<host>/pack-<abc>.pack" part is not sensitive at
all, and what follows after that "public" part has some "nonce"
material that makes it sensitive?
> Changes since v1:
> - Removed non-POSIX flags in tests
> - More accurate regex for the non-encrypted packfile line
> - Dropped documentation change
> - Dropped redacting the die message in http-fetch
These are not for those who read "git log" in 3 months, as they may
not even have seen the "v1". But these are very helpful for those
who read the "v1" to see how good this round is. Please write such
material below the three-dash line.
> Signed-off-by: Ivan Frade <ifrade@xxxxxxxxxx>
> ---
i.e. here.
> fetch-pack: redact packfile urls in traces
>
> In some setups, packfile uris act as bearer token. It is not recommended
> to expose them plainly in logs, although in special circunstances (e.g.
> debug) it makes sense to write them.
>
> Redact the packfile-uri lines by default, unless the GIT_TRACE_REDACT
> variable is set to false. This mimics the redacting of the Authorization
> header in HTTP.
>
> Signed-off-by: Ivan Frade ifrade@xxxxxxxxxx
>
> cc: Ævar Arnfjörð Bjarmason avarab@xxxxxxxxx
And there is no need to duplicate the log message here ;-)
> diff --git a/fetch-pack.c b/fetch-pack.c
> index a9604f35a3e..05c85eeafa1 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -1518,7 +1518,16 @@ static void receive_wanted_refs(struct packet_reader *reader,
> static void receive_packfile_uris(struct packet_reader *reader,
> struct string_list *uris)
> {
> + int original_options;
> process_section_header(reader, "packfile-uris", 0);
> + /*
> + * In some setups, packfile-uris act as bearer tokens,
> + * redact them by default.
> + */
> + original_options = reader->options;
> + if (git_env_bool("GIT_TRACE_REDACT", 1))
> + reader->options |= PACKET_READ_REDACT_ON_TRACE;
> +
> while (packet_reader_read(reader) == PACKET_READ_NORMAL) {
> if (reader->pktlen < the_hash_algo->hexsz ||
> reader->line[the_hash_algo->hexsz] != ' ')
> @@ -1526,6 +1535,8 @@ static void receive_packfile_uris(struct packet_reader *reader,
>
> string_list_append(uris, reader->line);
> }
> + reader->options = original_options;
So "original_options" is used to save away the reader->options so
that it can be restored before returning to our caller?
OK (it may be more common in this codebase to call such a variable
"saved_X", though).
> diff --git a/pkt-line.c b/pkt-line.c
> index de4a94b437e..8da8ed88ccf 100644
> --- a/pkt-line.c
> +++ b/pkt-line.c
> @@ -443,7 +443,12 @@ enum packet_read_status packet_read_with_status(int fd, char **src_buffer,
> len--;
>
> buffer[len] = 0;
> - packet_trace(buffer, len, 0);
> + if (options & PACKET_READ_REDACT_ON_TRACE) {
> + const char *redacted = "<redacted>";
> + packet_trace(redacted, strlen(redacted), 0);
> + } else {
> + packet_trace(buffer, len, 0);
> + }
> ...
> + GIT_TRACE=1 GIT_TRACE_PACKET="$(pwd)/log" GIT_TEST_SIDEBAND_ALL=1 \
> + git -c protocol.version=2 \
> + -c fetch.uriprotocols=http,https \
> + clone "$HTTPD_URL/smart/http_parent" http_child &&
> +
> + grep "clone< <redacted>" log
This checks only that "redacted" string appears, but what the theme
of the change really cares about is different, no? You want to
ensure that no sensitive substring of the URI appears in the log.
Imagine somebody breaking the redact logic by making it prepend that
string to the payload, instead of replacing the payload with that
string---this test will not catch such a regression.
Thanks.
