Re: [PATCH] Add persistent-https to contrib

Shawn Pearce [off-list ref] writes:

The persistent-https code tells the git credential helper the
connection is "secure" (that is the proxy will use SSL as it exits the
local machine) by setting GIT_GOOGLE_CREDENTIAL_CORPSSO_ENABLE=1 in
the environment. This leaked from our internal version of the proxy,
Colby was supposed to scrub this string before open sourcing. :-)

So now everyone knows $DAYJOB = Google, we have a credential helper,
and it supports some sort of corporate single sign on. Whee.

It is obviously needed to drop that bit from the public version (and have
you guys keep an internal fork to add it back), but I have to wonder if
this is an indication that something like that is useful in general.

More specifically, this environment variable is a way to tell the wrapped
helper who is wrapping it.  Users outside Google's environment of the
persistent-https helper obviously would not care about the corporate
sanitary sewer overflow mechanism, but they may have a similar need to
tweak what happens inside the git-remote-http that is driven by the
persistent helper. They would not care about "we can enable corpsso", but
they would benefit from knowing that either:

 (1) the connection is "secure" (by the definition above); or
 (2) the connection is going to this particular helper.

Conceptually, an approach to allow chain of helpers tell which one(s) of
defined set of attributes (e.g. "secure") are in effect, e.g. (1), might
be cleaner, but it probably is a bit too early overengineering (I do not
think we know if there is a good set of common attributes various helpers
might want to implement upstream and pay attention downstream) at this
point.  But at least it might not hurt to give the downstream to find out
what upstream is driving them.

Hrm?