All of
 help / color / mirror / Atom feed
From: Jeff King <>
To: Junio C Hamano <>
Cc: Jonathan Tan <>,,
Subject: Re: [PATCH v2 0/3] Safer GIT_CURL_VERBOSE
Date: Fri, 15 May 2020 16:47:29 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, May 13, 2020 at 12:33:37PM -0700, Junio C Hamano wrote:

> Junio C Hamano <> writes:
> > Jonathan Tan <> writes:
> >
> >> Thanks everyone. I went ahead with GIT_REDACT_AUTHORIZATION to match
> >> GIT_REDACT_COOKIES, with the default being true (i.e. you need to set it
> >> to "0" to have behavior change).
> >
> > Hmm, I would actually have expected us to move in the direction of
> > deprecating specific REDACT_BLAH and consolidate them into one,
> > instead of adding another one.  Especially as the primary reason why
> > we redact cookies is to protect those that are used for auth anyway.
> Also I had forgot to grep for anonymi.e to find transport_anonymize_url(),
> which I was hoping that the new environment variable would cover to help
> those who debug.

Yeah, I'd agree with both of these. If Jonathan doesn't feel like
working on transport_anonymize_url() now, I don't mind if we leave that
for later. But let's come up with a general scheme that we're aiming
for, so we minimize changes to things that users are exposed to.

IMHO an option that only impacts the format of the human-readable trace
output is not something we need to deprecate. It's an internal detail,
and people can't rely on the exact format of the trace anyway. So I'd be
fine to just kill off GIT_REDACT_COOKIES completely (especially if the
default behavior is the safer "always redact").

That said, a boolean GIT_REDACT doesn't quite do the same thing, because
it's actually a list of cookies. My gut feeling is that this is a bit
over-engineered. Any cookies that Git uses are likely to be sensitive,
so just treating their values like auth (redacting by default, but
allowing them to be unblinded when the user asks for it). But maybe
Jonathan had a specific tracing case in mind, as the author of the


      reply	other threads:[~2020-05-15 20:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-11 17:43 [PATCH 0/2] " Jonathan Tan
2020-05-11 17:43 ` [PATCH 1/2] t5551: test that GIT_TRACE_CURL redacts password Jonathan Tan
2020-05-12 19:08   ` Jeff King
2020-05-11 17:43 ` [PATCH 2/2] http, imap-send: stop using CURLOPT_VERBOSE Jonathan Tan
2020-05-12 19:16   ` Jeff King
2020-05-12 19:23     ` Jonathan Tan
2020-05-12 19:27       ` Jeff King
2020-05-12 23:13   ` brian m. carlson
2020-05-13  0:10     ` Junio C Hamano
2020-05-13  4:50       ` Jeff King
2020-05-13  5:05         ` Junio C Hamano
2020-05-13  6:16     ` Daniel Stenberg
2020-05-13 14:45       ` Jeff King
2020-05-13 19:12 ` [PATCH v2 0/3] Safer GIT_CURL_VERBOSE Jonathan Tan
2020-05-13 19:12   ` [PATCH v2 1/3] t5551: test that GIT_TRACE_CURL redacts password Jonathan Tan
2020-05-13 19:12   ` [PATCH v2 2/3] http: make GIT_TRACE_CURL auth redaction optional Jonathan Tan
2020-05-13 19:29     ` Junio C Hamano
2020-05-13 19:12   ` [PATCH v2 3/3] http, imap-send: stop using CURLOPT_VERBOSE Jonathan Tan
2020-05-13 19:27   ` [PATCH v2 0/3] Safer GIT_CURL_VERBOSE Junio C Hamano
2020-05-13 19:33     ` Junio C Hamano
2020-05-15 20:47       ` Jeff King [this message]

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:

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

  git send-email \ \ \ \ \ \ \
    --subject='Re: [PATCH v2 0/3] Safer GIT_CURL_VERBOSE' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.