Re: [PATCH/RFC] contrib: add win32 credential-helper

Jeff King [off-list ref] writes:

On Wed, Apr 04, 2012 at 12:37:25PM +0200, Erik Faye-Lund wrote:
...

quoted

The problem is that for some helpers you need to know the encoding in
order to have a user-interface show the data. This goes both for OSX
and Windows. If you mess up the encoding, in the helper, then you'll
mess up the entries in the OS'es key-managers. While this might not be
a problem in practice for US-English users, we've seen for Git for
Windows that e.g. some Asians are really unhappy with their username
becoming some completely incomprehensible string.

How are they inputting their username? If they are seeing garbage, then
surely it is coming to git in some encoding that is different than what
the password manager expects. Then we give it to a helper, which hands
it to system storage, which assumes that what we give it is utf-8. So
the error there seems to me to be the layer between the helper and the
system storage, where the string is converted from "a stream of bytes"
to "a utf-8 encoded string".

So why is this a credential helper protocol problem, and not an
implementation issue for the specific helper? How does git find out the
encoding? Presumably by checking $LANG, or whatever system-specific
locale information there is. Can't the helper do the same thing?

FWIW, this matches exactly my reaction.

If a helper on a specific system somehow *knows* the user means to give
UTF-8, uses system UI that interacts with the user and gives UTF-16 back,
and uses system store that takes UCS-2, it is entirely sensible for the
helper to convert between these encodings internally and use UTF-8 when
interacting with credential-helper API which only expects "stream of
bytes".  But that is just a specific implementation detail of the helper.