credential.c: fix credential reading with regards to CR/LF
diff mbox series

Message ID pull.710.git.git.1581688196706.gitgitgadget@gmail.com
State New
Headers show
Series
  • credential.c: fix credential reading with regards to CR/LF
Related show

Commit Message

Teng Long via GitGitGadget Feb. 14, 2020, 1:49 p.m. UTC
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>
---
    Prepare git credential to read input with DOS line endings
    
    This just came in via Git for Windows
    [https://github.com/git-for-windows/git/pull/2516].

Published-As: https://github.com/gitgitgadget/git/releases/tag/pr-git-710%2Fdscho%2Fcrlf-aware-git-credential-v1
Fetch-It-Via: git fetch https://github.com/gitgitgadget/git pr-git-710/dscho/crlf-aware-git-credential-v1
Pull-Request: https://github.com/git/git/pull/710

 credential.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


base-commit: d8437c57fa0752716dde2d3747e7c22bf7ce2e41

Comments

Junio C Hamano Feb. 14, 2020, 5:55 p.m. UTC | #1
"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.
Jeff King Feb. 14, 2020, 6:32 p.m. UTC | #2
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

Patch
diff mbox series

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, '=');