| Message ID | pull.710.git.git.1581688196706.gitgitgadget@gmail.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | credential.c: fix credential reading with regards to CR/LF | expand |
"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com> writes: > From: Nikita Leonov <nykyta.leonov@gmail.com> > > This fix makes using Git credentials more friendly to Windows users. In > previous version it was unable to finish input correctly without > configuration changes (tested in PowerShell, CMD, Cygwin). > > We know credential filling should be finished by empty input, but the > current implementation does not take into account CR/LF ending, and > hence instead of the empty string we get '\r', which is interpreted as > an incorrect string. > > So this commit changes default reading function to a more Windows > compatible reading function. > > Signed-off-by: Nikita Leonov <nykyta.leonov@gmail.com> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> > --- In the older days, strbuf_getline() used to be what we have as strbuf_getdelim() today, i.e. explicitly request what record separator to use to grab a line. The use of strbuf_getline_lf() we see in the pre-image of this patch came from 8f309aeb ("strbuf: introduce strbuf_getline_{lf,nul}()", 2016-01-13), which mechanically replaced the use of strbuf_getline(... '\n'), in anticipation for later effort to identify ones that are better to accept CRLF and turn them into _crlf variant. Later all the callers of (old) strbuf_getline() went away, and strbuf_getline_crlf() that allowed both LF and CRLF termination (which is most friendly to human-readable line of text) took over the shortest and sweetest name, strbuf_getline(). So, the "later" effort just happend to this code. It was a bit overdue, but it's better late than never. > credential.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/credential.c b/credential.c > index 62be651b03..65989dfa4d 100644 > --- a/credential.c > +++ b/credential.c > @@ -146,7 +146,7 @@ int credential_read(struct credential *c, FILE *fp) > { > struct strbuf line = STRBUF_INIT; > > - while (strbuf_getline_lf(&line, fp) != EOF) { > + while (strbuf_getline(&line, fp) != EOF) { > char *key = line.buf; > char *value = strchr(key, '='); There are many more conversions of strbuf_getline(..., '\n') to strbuf_getline_lf(...) made by 8f309aeb to other parts of credential stuff. Has anybody from the Windows side made sure these other ones are also better to accept CRLF, too? I'd wait for a bit to hear either "oh, we found two more and here is an updated patch" or "we looked at them and this is the only one", before touching this patch. Thanks.
On Fri, Feb 14, 2020 at 01:49:56PM +0000, Johannes Schindelin via GitGitGadget wrote: > From: Nikita Leonov <nykyta.leonov@gmail.com> > > This fix makes using Git credentials more friendly to Windows users. In > previous version it was unable to finish input correctly without > configuration changes (tested in PowerShell, CMD, Cygwin). > > We know credential filling should be finished by empty input, but the > current implementation does not take into account CR/LF ending, and > hence instead of the empty string we get '\r', which is interpreted as > an incorrect string. > > So this commit changes default reading function to a more Windows > compatible reading function. This does make it impossible to have a CR at the end of a data value. I think that should be OK (we already disallow LF with no mechanism for quoting, because who the hell puts a LF in their password?). But we should perhaps update the section in git-credential(1) that describes the rules. I had trouble coming up with a wording that wasn't totally awkward, though: diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt index 6f0c7ca80f..09e4b58321 100644 --- a/Documentation/git-credential.txt +++ b/Documentation/git-credential.txt @@ -112,7 +112,9 @@ specified by a key-value pair, separated by an `=` (equals) sign, followed by a newline. The key may contain any bytes except `=`, newline, or NUL. The value may contain any bytes except newline or NUL. In both cases, all bytes are treated as-is (i.e., there is no quoting, -and one cannot transmit a value with newline or NUL in it). The list of +and one cannot transmit a value with newline or NUL in it). Note that +Git will treat a carriage return before the final newline as part of +line ending, and not part of the data. The list of attributes is terminated by a blank line or end-of-file. Git understands the following attributes: This is talking about the git-credential tool itself, but the actual helper protocol documentation links to this. (As an aside, I notice that the protocol documentation recently got moved into credential.h along with the C API bits. Yuck. That probably should be in gitcredentials(7)). -Peff
diff --git a/credential.c b/credential.c index 62be651b03..65989dfa4d 100644 --- a/credential.c +++ b/credential.c @@ -146,7 +146,7 @@ int credential_read(struct credential *c, FILE *fp) { struct strbuf line = STRBUF_INIT; - while (strbuf_getline_lf(&line, fp) != EOF) { + while (strbuf_getline(&line, fp) != EOF) { char *key = line.buf; char *value = strchr(key, '=');