Subject: Re: [RFC PATCH] bugreport: also print value of no_proxy envvar

From: Glen Choo <[email-masked]>
Date: Mon, 27 Mar 2023 10:48:47 -0700

Junio C Hamano <[email-masked]> writes:

>> Taking off the author's hat and putting on the reviewer's hat, I'm
>> not so sure if this is the right approach, since $no_proxy might have
>> information that the user doesn't want to share (especially since it
>> could be used beyond the current repository, and even beyond Git), the
>> user being informed that they can delete any lines notwithstanding.
>
> [...]
>
> Or other environment variables like http_proxy may be causing harm
> to the user's use of Git, and inspecting no_proxy alone may not give
> you anything useful.  With devil's advocate hat on, I am tempted to
> suggest another approach at the the total opposite of the spectrum:
> dump everything in **environ and let the user edit out what ought to
> be private.  Intelligent ones may even notice a fishy setting they
> forgot about while trying to cull the report of these environment
> variables ;-)

For this series, I think the natural extension would be to grow the list
of environment variables to include everything that might affect Git?
I don't know how possible or sustainable that is, so Junio's idea (or
Junio's devil's advocate idea?) makes some sense from that perspective.
However, oversharing by default sounds far too unsafe to me.

Also, I suspect that dumping all of the environment variables might
sometimes be a hindrance. e.g. I can imagine a conservative user
removing $no_proxy. Then, on the other side, the report reader sees the
list of environment variables, assumes that since $no_proxy is unset
because it's absent from the report, and goes on a wild goose chase.

I wonder if it would be helpful to know that $no_proxy is set, even if
the report doesn't say what the value is. If so, an okay-ish middle
ground might be to dump all of the environment variables but redact them
by default (maybe something like git bugreport
--dump-envvars=[redact|no-redact]). I don't know how well this will work
in practice though. Personally, I'd still lean towards trimming down the
list of environment variables, even if the values are redacted.