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?

I do not mind carrying this in the contrib/ area (I am assuming that
distributing Apache licensed software that does not link with GPLv2 core
is OK).  It may be just me, but a file called COPYING that does not have
GPL text in it was a bit surprising.  I wonder if it is more customary to
call it either LICENSE (or perhaps LICENSE-2.0)?

Agreed. I'll change the name to LICENSE.

It might deserve its own contrib/persistent-https/Makefile in addition to
your internal "release" scripts, though.

OK. I'll update the code to use a simple Makefile for everything,
instead of the shell scripts.

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.

Agreed, I'll go with approach (1) and change the name of the var to be
GIT_PERSISTENT_HTTPS_SECURE. Also, I will update the code to remove
any GIT_PERSISTENT_HTTPS_SECURE from the environment.