Shawn Pearce <spearce@xxxxxxxxxxx> 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? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html