git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / mirror / Atom feed
* [PATCH] credential.c: fix credential reading with regards to CR/LF
@ 2020-02-14 13:49 Johannes Schindelin via GitGitGadget
  2020-02-14 17:55 ` Junio C Hamano
                   ` (2 more replies)
  0 siblings, 3 replies; 18+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-02-14 13:49 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin, Nikita Leonov

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(-)

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

base-commit: d8437c57fa0752716dde2d3747e7c22bf7ce2e41
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] credential.c: fix credential reading with regards to CR/LF
  2020-02-14 13:49 [PATCH] credential.c: fix credential reading with regards to CR/LF Johannes Schindelin via GitGitGadget
@ 2020-02-14 17:55 ` Junio C Hamano
  2020-02-14 18:32 ` Jeff King
  2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
  2 siblings, 0 replies; 18+ messages in thread
From: Junio C Hamano @ 2020-02-14 17:55 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Johannes Schindelin, Nikita Leonov

"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.




^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH] credential.c: fix credential reading with regards to CR/LF
  2020-02-14 13:49 [PATCH] credential.c: fix credential reading with regards to CR/LF Johannes Schindelin via GitGitGadget
  2020-02-14 17:55 ` Junio C Hamano
@ 2020-02-14 18:32 ` Jeff King
  2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
  2 siblings, 0 replies; 18+ messages in thread
From: Jeff King @ 2020-02-14 18:32 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget
  Cc: git, Johannes Schindelin, Nikita Leonov

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

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v2 0/3] Prepare git credential to read input with DOS line endings
  2020-02-14 13:49 [PATCH] credential.c: fix credential reading with regards to CR/LF Johannes Schindelin via GitGitGadget
  2020-02-14 17:55 ` Junio C Hamano
  2020-02-14 18:32 ` Jeff King
@ 2020-09-28 11:40 ` Johannes Schindelin via GitGitGadget
  2020-09-28 11:40   ` [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF Nikita Leonov via GitGitGadget
                     ` (3 more replies)
  2 siblings, 4 replies; 18+ messages in thread
From: Johannes Schindelin via GitGitGadget @ 2020-09-28 11:40 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin

This contribution came in via Git for Windows
[https://github.com/git-for-windows/git/pull/2516].

Sadly, I did not find the time to go through all the changes of 8f309aeb
("strbuf: introduce strbuf_getline_{lf,nul}()", 2016-01-13) (as Junio asked
[https://public-inbox.org/git/xmqqmu9lnjdh.fsf@gitster-ct.c.googlers.com]).
Rather than delaying this patch indefinitely, I admit defeat on that angle.

Changes since v1:

 * Added a commit to adjust credential-daemon and credential-store in the
   same manner.
 * Adjusted the documentation accordingly.

Nikita Leonov (3):
  credential.c: fix credential reading with regards to CR/LF
  credentials: make line reading Windows compatible
  docs: make notes regarding credential line reading

 Documentation/git-credential.txt   |  4 +++-
 Documentation/gitcredentials.txt   |  2 ++
 builtin/credential-cache--daemon.c |  4 ++--
 builtin/credential-store.c         |  2 +-
 credential.c                       |  2 +-
 t/t0302-credential-store.sh        | 16 ++++++----------
 6 files changed, 15 insertions(+), 15 deletions(-)


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

Range-diff vs v1:

 1:  2a9cc710bb = 1:  27f6400a21 credential.c: fix credential reading with regards to CR/LF
 -:  ---------- > 2:  f69076036f credentials: make line reading Windows compatible
 -:  ---------- > 3:  61baea1061 docs: make notes regarding credential line reading

-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF
  2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
@ 2020-09-28 11:40   ` Nikita Leonov via GitGitGadget
  2020-09-29  0:42     ` Jeff King
  2020-09-28 11:40   ` [PATCH v2 2/3] credentials: make line reading Windows compatible Nikita Leonov via GitGitGadget
                     ` (2 subsequent siblings)
  3 siblings, 1 reply; 18+ messages in thread
From: Nikita Leonov via GitGitGadget @ 2020-09-28 11:40 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin, Nikita Leonov

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>
---
 credential.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/credential.c b/credential.c
index efc29dc5e1..e5202fbef2 100644
--- a/credential.c
+++ b/credential.c
@@ -202,7 +202,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, '=');
 
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
  2020-09-28 11:40   ` [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF Nikita Leonov via GitGitGadget
@ 2020-09-28 11:40   ` Nikita Leonov via GitGitGadget
  2020-09-28 20:58     ` Junio C Hamano
  2020-09-28 23:26     ` Carlo Arenas
  2020-09-28 11:40   ` [PATCH v2 3/3] docs: make notes regarding credential line reading Nikita Leonov via GitGitGadget
  2020-09-28 20:31   ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Junio C Hamano
  3 siblings, 2 replies; 18+ messages in thread
From: Nikita Leonov via GitGitGadget @ 2020-09-28 11:40 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin, Nikita Leonov

From: Nikita Leonov <nykyta.leonov@gmail.com>

This commit makes reading process regarding credentials compatible with
'CR/LF' line ending. It makes using git more convenient on systems like
Windows.

Signed-off-by: Nikita Leonov <nykyta.leonov@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 builtin/credential-cache--daemon.c |  4 ++--
 builtin/credential-store.c         |  2 +-
 t/t0302-credential-store.sh        | 16 ++++++----------
 3 files changed, 9 insertions(+), 13 deletions(-)

diff --git a/builtin/credential-cache--daemon.c b/builtin/credential-cache--daemon.c
index c61f123a3b..17664bb0d5 100644
--- a/builtin/credential-cache--daemon.c
+++ b/builtin/credential-cache--daemon.c
@@ -99,12 +99,12 @@ static int read_request(FILE *fh, struct credential *c,
 	static struct strbuf item = STRBUF_INIT;
 	const char *p;
 
-	strbuf_getline_lf(&item, fh);
+	strbuf_getline(&item, fh);
 	if (!skip_prefix(item.buf, "action=", &p))
 		return error("client sent bogus action line: %s", item.buf);
 	strbuf_addstr(action, p);
 
-	strbuf_getline_lf(&item, fh);
+	strbuf_getline(&item, fh);
 	if (!skip_prefix(item.buf, "timeout=", &p))
 		return error("client sent bogus timeout line: %s", item.buf);
 	*timeout = atoi(p);
diff --git a/builtin/credential-store.c b/builtin/credential-store.c
index 5331ab151a..d4e90b68df 100644
--- a/builtin/credential-store.c
+++ b/builtin/credential-store.c
@@ -23,7 +23,7 @@ static int parse_credential_file(const char *fn,
 		return found_credential;
 	}
 
-	while (strbuf_getline_lf(&line, fh) != EOF) {
+	while (strbuf_getline(&line, fh) != EOF) {
 		if (!credential_from_url_gently(&entry, line.buf, 1) &&
 		    entry.username && entry.password &&
 		    credential_match(c, &entry)) {
diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh
index 716bf1af9f..f2c672e4b6 100755
--- a/t/t0302-credential-store.sh
+++ b/t/t0302-credential-store.sh
@@ -142,7 +142,7 @@ invalid_credential_test "scheme" ://user:pass@example.com
 invalid_credential_test "valid host/path" https://user:pass@
 invalid_credential_test "username/password" https://pass@example.com
 
-test_expect_success 'get: credentials with DOS line endings are invalid' '
+test_expect_success 'get: credentials with DOS line endings are valid' '
 	printf "https://user:pass@example.com\r\n" >"$HOME/.git-credentials" &&
 	check fill store <<-\EOF
 	protocol=https
@@ -150,11 +150,9 @@ test_expect_success 'get: credentials with DOS line endings are invalid' '
 	--
 	protocol=https
 	host=example.com
-	username=askpass-username
-	password=askpass-password
+	username=user
+	password=pass
 	--
-	askpass: Username for '\''https://example.com'\'':
-	askpass: Password for '\''https://askpass-username@example.com'\'':
 	--
 	EOF
 '
@@ -172,7 +170,7 @@ test_expect_success 'get: credentials with path and DOS line endings are valid'
 	EOF
 '
 
-test_expect_success 'get: credentials with DOS line endings are invalid if path is relevant' '
+test_expect_success 'get: credentials with DOS line endings are valid if path is relevant' '
 	printf "https://user:pass@example.com/repo.git\r\n" >"$HOME/.git-credentials" &&
 	test_config credential.useHttpPath true &&
 	check fill store <<-\EOF
@@ -181,11 +179,9 @@ test_expect_success 'get: credentials with DOS line endings are invalid if path
 	protocol=https
 	host=example.com
 	path=repo.git
-	username=askpass-username
-	password=askpass-password
+	username=user
+	password=pass
 	--
-	askpass: Username for '\''https://example.com/repo.git'\'':
-	askpass: Password for '\''https://askpass-username@example.com/repo.git'\'':
 	--
 	EOF
 '
-- 
gitgitgadget


^ permalink raw reply	[flat|nested] 18+ messages in thread

* [PATCH v2 3/3] docs: make notes regarding credential line reading
  2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
  2020-09-28 11:40   ` [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF Nikita Leonov via GitGitGadget
  2020-09-28 11:40   ` [PATCH v2 2/3] credentials: make line reading Windows compatible Nikita Leonov via GitGitGadget
@ 2020-09-28 11:40   ` Nikita Leonov via GitGitGadget
  2020-09-28 20:31   ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Junio C Hamano
  3 siblings, 0 replies; 18+ messages in thread
From: Nikita Leonov via GitGitGadget @ 2020-09-28 11:40 UTC (permalink / raw)
  To: git; +Cc: Johannes Schindelin, Nikita Leonov

From: Nikita Leonov <nykyta.leonov@gmail.com>

This commit adds notes to git-credential.txt and to gitcredentials.txt
specifying that 'LF' and 'CR/LF' endings are treated the same.

Signed-off-by: Nikita Leonov <nykyta.leonov@gmail.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-credential.txt | 4 +++-
 Documentation/gitcredentials.txt | 2 ++
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/Documentation/git-credential.txt b/Documentation/git-credential.txt
index 31c81c4c02..9cf25126f2 100644
--- a/Documentation/git-credential.txt
+++ b/Documentation/git-credential.txt
@@ -114,7 +114,9 @@ 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:
diff --git a/Documentation/gitcredentials.txt b/Documentation/gitcredentials.txt
index 758bf39ba3..184079eaa4 100644
--- a/Documentation/gitcredentials.txt
+++ b/Documentation/gitcredentials.txt
@@ -141,6 +141,8 @@ entry for `https://example.com/bar/baz.git` (in addition to matching the config
 entry for `https://example.com`) but will not match a config entry for
 `https://example.com/bar`.
 
+Note that Git will treat a carriage return before the final newline as part
+of line ending, and not part of the data.
 
 CONFIGURATION OPTIONS
 ---------------------
-- 
gitgitgadget

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 0/3] Prepare git credential to read input with DOS line endings
  2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
                     ` (2 preceding siblings ...)
  2020-09-28 11:40   ` [PATCH v2 3/3] docs: make notes regarding credential line reading Nikita Leonov via GitGitGadget
@ 2020-09-28 20:31   ` Junio C Hamano
  3 siblings, 0 replies; 18+ messages in thread
From: Junio C Hamano @ 2020-09-28 20:31 UTC (permalink / raw)
  To: Johannes Schindelin via GitGitGadget; +Cc: git, Johannes Schindelin

"Johannes Schindelin via GitGitGadget" <gitgitgadget@gmail.com>
writes:

> This contribution came in via Git for Windows
> [https://github.com/git-for-windows/git/pull/2516].
>
> Sadly, I did not find the time to go through all the changes of 8f309aeb
> ("strbuf: introduce strbuf_getline_{lf,nul}()", 2016-01-13) (as Junio asked
> [https://public-inbox.org/git/xmqqmu9lnjdh.fsf@gitster-ct.c.googlers.com]).
> Rather than delaying this patch indefinitely, I admit defeat on that angle.

Oh, that's OK.  Thanks for resurrecting the stalled patch.  I didn't
mean the suggested action while I was waiting to be an exhaustive
audit---I merely wanted to avoid having to queue a few more separate
ones soon after applying a patch for just a single place.

> Changes since v1:
>
>  * Added a commit to adjust credential-daemon and credential-store in the
>    same manner.

I am kind of surprised to see that these need to be touched at all.

The change to credential-store is sort-of understandable, as the
file it uses could be hand-modified in an editor and its line ending
could have been changed to CRLF, hence it needs to be prepared.

But does inter-process communication with the daemon need to care
about CRLF line endings?  Do parts of the protocol within the
credential system use platform specific line ending?

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-28 11:40   ` [PATCH v2 2/3] credentials: make line reading Windows compatible Nikita Leonov via GitGitGadget
@ 2020-09-28 20:58     ` Junio C Hamano
  2020-09-29  0:35       ` Jeff King
  2020-09-28 23:26     ` Carlo Arenas
  1 sibling, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2020-09-28 20:58 UTC (permalink / raw)
  To: Nikita Leonov via GitGitGadget; +Cc: git, Johannes Schindelin, Nikita Leonov

"Nikita Leonov via GitGitGadget" <gitgitgadget@gmail.com> writes:

> From: Nikita Leonov <nykyta.leonov@gmail.com>
>
> This commit makes reading process regarding credentials compatible with
> 'CR/LF' line ending. It makes using git more convenient on systems like
> Windows.

I can see why this is a good thing for "store" and the two updated
pieces of the test script demonstrate it very well.  

But it is unclear why and how cache-daemon benefits from this change.
That needs to be justified.

As to the log message (this is 70% style, but there are
consequences), we tend not to say "This commit does X"---because
such a statement is often insufficient to illustrate if the commit
indeed does X, and explain why it is a good thing to do X in the
first place.

Instead, we first explain that the current system does not do X (in
present tense, so we do NOT say "previously we did not do X"), then
explain why doing X would be a good thing, and finally give an order
to the codebase to start doing X.  For this change, it might look
like this:

    The credential subsystem has assumed that lines always end with
    LF.  On a system whose text file ends with CRLF (e.g. Windows),
    this assumption causes the CR at the end of the line as an extra
    byte appended to the data, and worse, there is no way to send an
    "empty line" to signal an end of a group of lines, because such
    a line would be taken as a line with a lone CR on it.

    Because credential-store writes to and reads from a text file on
    disk, which users may manually edit with their editor and turn
    the line-ending to CRLF.

    Accept lines that end with CR/LF, as well as those that end with
    LF.

    Note that the credential-cache--daemon is not touched, because
    it is only about interacting with in-core cache, and there is
    nowhere CRLF comes into the picture.



Note: I didn't know why we need to touch the daemon, and that is why
I wrote the paragraph on it as such, but I expect that the real log
message to justify the change would be quite different and explain
why the daemon code needs the same change well---such a description
would not be "Note that", but would come before the "Accept lines
that end with..." and after the paragraph about credential-store.

Thanks.

> Signed-off-by: Nikita Leonov <nykyta.leonov@gmail.com>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>  builtin/credential-cache--daemon.c |  4 ++--
>  builtin/credential-store.c         |  2 +-
>  t/t0302-credential-store.sh        | 16 ++++++----------
>  3 files changed, 9 insertions(+), 13 deletions(-)
>
> diff --git a/builtin/credential-cache--daemon.c b/builtin/credential-cache--daemon.c
> index c61f123a3b..17664bb0d5 100644
> --- a/builtin/credential-cache--daemon.c
> +++ b/builtin/credential-cache--daemon.c
> @@ -99,12 +99,12 @@ static int read_request(FILE *fh, struct credential *c,
>  	static struct strbuf item = STRBUF_INIT;
>  	const char *p;
>  
> -	strbuf_getline_lf(&item, fh);
> +	strbuf_getline(&item, fh);
>  	if (!skip_prefix(item.buf, "action=", &p))
>  		return error("client sent bogus action line: %s", item.buf);
>  	strbuf_addstr(action, p);
>  
> -	strbuf_getline_lf(&item, fh);
> +	strbuf_getline(&item, fh);
>  	if (!skip_prefix(item.buf, "timeout=", &p))
>  		return error("client sent bogus timeout line: %s", item.buf);
>  	*timeout = atoi(p);
> diff --git a/builtin/credential-store.c b/builtin/credential-store.c
> index 5331ab151a..d4e90b68df 100644
> --- a/builtin/credential-store.c
> +++ b/builtin/credential-store.c
> @@ -23,7 +23,7 @@ static int parse_credential_file(const char *fn,
>  		return found_credential;
>  	}
>  
> -	while (strbuf_getline_lf(&line, fh) != EOF) {
> +	while (strbuf_getline(&line, fh) != EOF) {
>  		if (!credential_from_url_gently(&entry, line.buf, 1) &&
>  		    entry.username && entry.password &&
>  		    credential_match(c, &entry)) {
> diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh
> index 716bf1af9f..f2c672e4b6 100755
> --- a/t/t0302-credential-store.sh
> +++ b/t/t0302-credential-store.sh
> @@ -142,7 +142,7 @@ invalid_credential_test "scheme" ://user:pass@example.com
>  invalid_credential_test "valid host/path" https://user:pass@
>  invalid_credential_test "username/password" https://pass@example.com
>  
> -test_expect_success 'get: credentials with DOS line endings are invalid' '
> +test_expect_success 'get: credentials with DOS line endings are valid' '
>  	printf "https://user:pass@example.com\r\n" >"$HOME/.git-credentials" &&
>  	check fill store <<-\EOF
>  	protocol=https
> @@ -150,11 +150,9 @@ test_expect_success 'get: credentials with DOS line endings are invalid' '
>  	--
>  	protocol=https
>  	host=example.com
> -	username=askpass-username
> -	password=askpass-password
> +	username=user
> +	password=pass
>  	--
> -	askpass: Username for '\''https://example.com'\'':
> -	askpass: Password for '\''https://askpass-username@example.com'\'':
>  	--
>  	EOF
>  '
> @@ -172,7 +170,7 @@ test_expect_success 'get: credentials with path and DOS line endings are valid'
>  	EOF
>  '
>  
> -test_expect_success 'get: credentials with DOS line endings are invalid if path is relevant' '
> +test_expect_success 'get: credentials with DOS line endings are valid if path is relevant' '
>  	printf "https://user:pass@example.com/repo.git\r\n" >"$HOME/.git-credentials" &&
>  	test_config credential.useHttpPath true &&
>  	check fill store <<-\EOF
> @@ -181,11 +179,9 @@ test_expect_success 'get: credentials with DOS line endings are invalid if path
>  	protocol=https
>  	host=example.com
>  	path=repo.git
> -	username=askpass-username
> -	password=askpass-password
> +	username=user
> +	password=pass
>  	--
> -	askpass: Username for '\''https://example.com/repo.git'\'':
> -	askpass: Password for '\''https://askpass-username@example.com/repo.git'\'':
>  	--
>  	EOF
>  '

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-28 11:40   ` [PATCH v2 2/3] credentials: make line reading Windows compatible Nikita Leonov via GitGitGadget
  2020-09-28 20:58     ` Junio C Hamano
@ 2020-09-28 23:26     ` Carlo Arenas
  2020-09-28 23:41       ` Junio C Hamano
  2020-09-29  0:30       ` Jeff King
  1 sibling, 2 replies; 18+ messages in thread
From: Carlo Arenas @ 2020-09-28 23:26 UTC (permalink / raw)
  To: Nikita Leonov via GitGitGadget
  Cc: git, Johannes Schindelin, Nikita Leonov, peff

On Mon, Sep 28, 2020 at 4:41 AM Nikita Leonov via GitGitGadget
<gitgitgadget@gmail.com> wrote:
> diff --git a/t/t0302-credential-store.sh b/t/t0302-credential-store.sh
> index 716bf1af9f..f2c672e4b6 100755
> --- a/t/t0302-credential-store.sh
> +++ b/t/t0302-credential-store.sh
> @@ -142,7 +142,7 @@ invalid_credential_test "scheme" ://user:pass@example.com
>  invalid_credential_test "valid host/path" https://user:pass@
>  invalid_credential_test "username/password" https://pass@example.com
>
> -test_expect_success 'get: credentials with DOS line endings are invalid' '
> +test_expect_success 'get: credentials with DOS line endings are valid' '
>         printf "https://user:pass@example.com\r\n" >"$HOME/.git-credentials" &&
>         check fill store <<-\EOF
>         protocol=https
> @@ -150,11 +150,9 @@ test_expect_success 'get: credentials with DOS line endings are invalid' '
>         --
>         protocol=https
>         host=example.com
> -       username=askpass-username
> -       password=askpass-password
> +       username=user
> +       password=pass
>         --
> -       askpass: Username for '\''https://example.com'\'':
> -       askpass: Password for '\''https://askpass-username@example.com'\'':
>         --
>         EOF
>  '
> @@ -172,7 +170,7 @@ test_expect_success 'get: credentials with path and DOS line endings are valid'
>         EOF
>  '
>
> -test_expect_success 'get: credentials with DOS line endings are invalid if path is relevant' '
> +test_expect_success 'get: credentials with DOS line endings are valid if path is relevant' '

note that this test was put in place to protect users from regressions
like the one we got after the release of 2.26.1 where users that had
'\r' as part of their credentials were getting an error[1]

while I am sympathetic to the change (indeed I proposed something
similar, but was reminded by Peff that while it looks like a text file
it was designed to be considered opaque and therefore should use UNIX
LF as record terminator by specification), I am concerned this could
result in a similar regression since we know they are still users out
there that had modified this file manually (something that was not
recommended) and are currently relying on the fact that these lines
are invalid and therefore silently ignored.

Carlo

[1] https://lore.kernel.org/git/ad80aa0d-3a35-6d7e-7958-b3520e16c855@ed4u.de/

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-28 23:26     ` Carlo Arenas
@ 2020-09-28 23:41       ` Junio C Hamano
  2020-09-29  0:30       ` Jeff King
  1 sibling, 0 replies; 18+ messages in thread
From: Junio C Hamano @ 2020-09-28 23:41 UTC (permalink / raw)
  To: Carlo Arenas
  Cc: Nikita Leonov via GitGitGadget, git, Johannes Schindelin,
	Nikita Leonov, peff

Carlo Arenas <carenas@gmail.com> writes:

>> -test_expect_success 'get: credentials with DOS line endings are invalid if path is relevant' '
>> +test_expect_success 'get: credentials with DOS line endings are valid if path is relevant' '
>
> note that this test was put in place to protect users from regressions
> like the one we got after the release of 2.26.1 where users that had
> '\r' as part of their credentials were getting an error[1]
>
> while I am sympathetic to the change (indeed I proposed something
> similar, but was reminded by Peff that while it looks like a text file
> it was designed to be considered opaque and therefore should use UNIX
> LF as record terminator by specification), I am concerned this could
> result in a similar regression since we know they are still users out
> there that had modified this file manually (something that was not
> recommended) and are currently relying on the fact that these lines
> are invalid and therefore silently ignored.
>
> Carlo
>
> [1] https://lore.kernel.org/git/ad80aa0d-3a35-6d7e-7958-b3520e16c855@ed4u.de/

I think you meant to remind us and this thread of the earlier review
and discussion thread, which begins at

  https://lore.kernel.org/git/20200426234750.40418-1-carenas@gmail.com/

And thanks for doing so---I totally forgot about it.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-28 23:26     ` Carlo Arenas
  2020-09-28 23:41       ` Junio C Hamano
@ 2020-09-29  0:30       ` Jeff King
  2020-09-29  0:41         ` Junio C Hamano
  1 sibling, 1 reply; 18+ messages in thread
From: Jeff King @ 2020-09-29  0:30 UTC (permalink / raw)
  To: Carlo Arenas
  Cc: Nikita Leonov via GitGitGadget, git, Johannes Schindelin, Nikita Leonov

On Mon, Sep 28, 2020 at 04:26:38PM -0700, Carlo Arenas wrote:

> > -test_expect_success 'get: credentials with DOS line endings are invalid if path is relevant' '
> > +test_expect_success 'get: credentials with DOS line endings are valid if path is relevant' '
> 
> note that this test was put in place to protect users from regressions
> like the one we got after the release of 2.26.1 where users that had
> '\r' as part of their credentials were getting an error[1]
> 
> while I am sympathetic to the change (indeed I proposed something
> similar, but was reminded by Peff that while it looks like a text file
> it was designed to be considered opaque and therefore should use UNIX
> LF as record terminator by specification), I am concerned this could
> result in a similar regression since we know they are still users out
> there that had modified this file manually (something that was not
> recommended) and are currently relying on the fact that these lines
> are invalid and therefore silently ignored.

Going over that old thread, I'm not sure that anybody raised a real use
case where somebody expected a CR at the end of a line. The discussion
was mostly about whether proposed changes would or would not be
compatible with existing behavior.

I think that:

  - we'd never write a raw CR ourselves, as we'd urlencode the character

  - if somebody did put in a raw CR manually like:

      https://example.com\r\n

    then we'd currently fail to match "example.com". Which is probably
    not what they wanted. I suspect that \r in a hostname is bogus
    anyway (certainly curl will complain about it).

  - you could do the same in a path:

      https://example.com/foo\r\n

    which _is_ legal, but I think we'd generally ignore it completely
    unless credential.usehttppath is set (for network-accessible
    requests, that is; you could probably point your local cert file at
    something bogus, but I think the main areas of interest here are
    people manipulating the credential protocol via malicious urls).

So I'm OK loosening the format in the name of convenience, as long as
we're confident that it's not opening up any security problems. I can't
think of any such problems, though.

It sounds from your email like you may have found me arguing the
opposite. That's entirely possible. ;) But I couldn't find it in the
thread Junio linked.

-Peff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-28 20:58     ` Junio C Hamano
@ 2020-09-29  0:35       ` Jeff King
  0 siblings, 0 replies; 18+ messages in thread
From: Jeff King @ 2020-09-29  0:35 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Nikita Leonov via GitGitGadget, git, Johannes Schindelin, Nikita Leonov

On Mon, Sep 28, 2020 at 01:58:03PM -0700, Junio C Hamano wrote:

> "Nikita Leonov via GitGitGadget" <gitgitgadget@gmail.com> writes:
> 
> > From: Nikita Leonov <nykyta.leonov@gmail.com>
> >
> > This commit makes reading process regarding credentials compatible with
> > 'CR/LF' line ending. It makes using git more convenient on systems like
> > Windows.
> 
> I can see why this is a good thing for "store" and the two updated
> pieces of the test script demonstrate it very well.  
> 
> But it is unclear why and how cache-daemon benefits from this change.
> That needs to be justified.

I suspect it doesn't need touched, because it is internal to git-daemon.
But it does handle CRLF for some lines, because the first patch
modified credential_read(), which the daemon builds on (and which _is_
user-facing via git-credential). So there's perhaps an argument that
these calls should just be made consistent, even though the only one who
would write them is our matching client. If that is the argument to be
made, I think it would make sense to do so in a separate patch, since
there's no functional change.

(I'm also slightly puzzled that anybody on Windows would care about
credential-cache, since it require unix sockets. But maybe in a world of
WSL people are actually able to mix the two. I confess I haven't kept up
with the state of things in Windows).

-Peff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-29  0:30       ` Jeff King
@ 2020-09-29  0:41         ` Junio C Hamano
  2020-09-29  0:44           ` Jeff King
  0 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2020-09-29  0:41 UTC (permalink / raw)
  To: Jeff King
  Cc: Carlo Arenas, Nikita Leonov via GitGitGadget, git,
	Johannes Schindelin, Nikita Leonov

Jeff King <peff@peff.net> writes:

> I think that:
>
>   - we'd never write a raw CR ourselves, as we'd urlencode the character
>
>   - if somebody did put in a raw CR manually like:
>
>       https://example.com\r\n
>
>     then we'd currently fail to match "example.com". Which is probably
>     not what they wanted. I suspect that \r in a hostname is bogus
>     anyway (certainly curl will complain about it).

I may be misremembering, but an argument I recall against the kind
of change we are dicussing now was that we ignore such an entry
right now, and the user may have added an entry for the host anew,
possibly with a more recent password.  Changing the parsing to
ignore CR would silently resurrect such a stale entry that the user
has written off as unused, and depending on the order of entries in
the file, a site that used to work may start failing suddenly.

I don't think I'd care too heavily either way.  As long as other
people will deal with possible backward-incompatibility fallout,
I do not mind seeing the change ;-).

I still don't see why we need to touch the cache-daemon, though.

Thanks.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF
  2020-09-28 11:40   ` [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF Nikita Leonov via GitGitGadget
@ 2020-09-29  0:42     ` Jeff King
  0 siblings, 0 replies; 18+ messages in thread
From: Jeff King @ 2020-09-29  0:42 UTC (permalink / raw)
  To: Nikita Leonov via GitGitGadget; +Cc: git, Johannes Schindelin, Nikita Leonov

On Mon, Sep 28, 2020 at 11:40:22AM +0000, Nikita Leonov 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.

Unlike the credential-store file case, where we expect the data to be
URL-encoded anyway (and so any true "\r" in the data would not be found
in raw form), this means that the credential protocol can no longer
represent "\r" at the end of a value.

And we'd match "example.com\r" and "example.com" as the same (unlikely,
since carriage returns aren't allowed in hostnames, and curl will
complain about this). We'd also match "cert://some/path\r" and
"cert://some/path". Or "https://example.com/path\r" and its match, if
you have credential.useHTTPPath set.

That may be acceptable if it makes things more convenient. Those are all
pretty obscure cases, and I find it hard to believe an attacker could
hijack credentials using this (it implies that the only difference
between their malicious url and a known-good one is a trailing CR).

This part of the commit message confused me a little:

> 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.

If all we care about is the empty line, and not data lines, then we
could do this:

diff --git a/credential.c b/credential.c
index efc29dc5e1..73143c5ed0 100644
--- a/credential.c
+++ b/credential.c
@@ -206,7 +206,7 @@ int credential_read(struct credential *c, FILE *fp)
 		char *key = line.buf;
 		char *value = strchr(key, '=');
 
-		if (!line.len)
+		if (!line.len || (line.len == 1 && line.buf[0] == '\r'))
 			break;
 
 		if (!value) {

without impacting the ability to send raw CR in the lines with actual
data. But I imagine that a trailing CR in all of the data would also
cause problems.

-Peff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-29  0:41         ` Junio C Hamano
@ 2020-09-29  0:44           ` Jeff King
  2020-09-29  0:54             ` Junio C Hamano
  0 siblings, 1 reply; 18+ messages in thread
From: Jeff King @ 2020-09-29  0:44 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Carlo Arenas, Nikita Leonov via GitGitGadget, git,
	Johannes Schindelin, Nikita Leonov

On Mon, Sep 28, 2020 at 05:41:14PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > I think that:
> >
> >   - we'd never write a raw CR ourselves, as we'd urlencode the character
> >
> >   - if somebody did put in a raw CR manually like:
> >
> >       https://example.com\r\n
> >
> >     then we'd currently fail to match "example.com". Which is probably
> >     not what they wanted. I suspect that \r in a hostname is bogus
> >     anyway (certainly curl will complain about it).
> 
> I may be misremembering, but an argument I recall against the kind
> of change we are dicussing now was that we ignore such an entry
> right now, and the user may have added an entry for the host anew,
> possibly with a more recent password.  Changing the parsing to
> ignore CR would silently resurrect such a stale entry that the user
> has written off as unused, and depending on the order of entries in
> the file, a site that used to work may start failing suddenly.

Yeah, that is probably what would happen. I have to admit that it's such
an obscure case that I'm not sure I really care. It's unlikely in
practice, and if somebody did report such a case, I think my first
response would be "well, why did you have a broken entry stuck in your
file?".

> I still don't see why we need to touch the cache-daemon, though.

Yeah, I touched on that more in another response.

-Peff

^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-29  0:44           ` Jeff King
@ 2020-09-29  0:54             ` Junio C Hamano
  2020-09-29  3:00               ` Jeff King
  0 siblings, 1 reply; 18+ messages in thread
From: Junio C Hamano @ 2020-09-29  0:54 UTC (permalink / raw)
  To: Jeff King
  Cc: Carlo Arenas, Nikita Leonov via GitGitGadget, git,
	Johannes Schindelin, Nikita Leonov

Jeff King <peff@peff.net> writes:

> Yeah, that is probably what would happen. I have to admit that it's such
> an obscure case that I'm not sure I really care. It's unlikely in
> practice, and if somebody did report such a case, I think my first
> response would be "well, why did you have a broken entry stuck in your
> file?".

I think we know the likely answer.  "I once used Windows to edit the
file manually".

After which the file looks broken, so the user may have re-added via
the credential API (with LF line ending) a new entry for the host
and have been happily using the result.


^ permalink raw reply	[flat|nested] 18+ messages in thread

* Re: [PATCH v2 2/3] credentials: make line reading Windows compatible
  2020-09-29  0:54             ` Junio C Hamano
@ 2020-09-29  3:00               ` Jeff King
  0 siblings, 0 replies; 18+ messages in thread
From: Jeff King @ 2020-09-29  3:00 UTC (permalink / raw)
  To: Junio C Hamano
  Cc: Carlo Arenas, Nikita Leonov via GitGitGadget, git,
	Johannes Schindelin, Nikita Leonov

On Mon, Sep 28, 2020 at 05:54:37PM -0700, Junio C Hamano wrote:

> Jeff King <peff@peff.net> writes:
> 
> > Yeah, that is probably what would happen. I have to admit that it's such
> > an obscure case that I'm not sure I really care. It's unlikely in
> > practice, and if somebody did report such a case, I think my first
> > response would be "well, why did you have a broken entry stuck in your
> > file?".
> 
> I think we know the likely answer.  "I once used Windows to edit the
> file manually".
> 
> After which the file looks broken, so the user may have re-added via
> the credential API (with LF line ending) a new entry for the host
> and have been happily using the result.

I wrote something less charitable towards the user at first, and then
toned it down. But I think I toned it down too much. Maybe my response
would be "garbage in, garbage out; it was lucky that it worked before".

-Peff

^ permalink raw reply	[flat|nested] 18+ messages in thread

end of thread, other threads:[~2020-09-29  3:00 UTC | newest]

Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-14 13:49 [PATCH] credential.c: fix credential reading with regards to CR/LF Johannes Schindelin via GitGitGadget
2020-02-14 17:55 ` Junio C Hamano
2020-02-14 18:32 ` Jeff King
2020-09-28 11:40 ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Johannes Schindelin via GitGitGadget
2020-09-28 11:40   ` [PATCH v2 1/3] credential.c: fix credential reading with regards to CR/LF Nikita Leonov via GitGitGadget
2020-09-29  0:42     ` Jeff King
2020-09-28 11:40   ` [PATCH v2 2/3] credentials: make line reading Windows compatible Nikita Leonov via GitGitGadget
2020-09-28 20:58     ` Junio C Hamano
2020-09-29  0:35       ` Jeff King
2020-09-28 23:26     ` Carlo Arenas
2020-09-28 23:41       ` Junio C Hamano
2020-09-29  0:30       ` Jeff King
2020-09-29  0:41         ` Junio C Hamano
2020-09-29  0:44           ` Jeff King
2020-09-29  0:54             ` Junio C Hamano
2020-09-29  3:00               ` Jeff King
2020-09-28 11:40   ` [PATCH v2 3/3] docs: make notes regarding credential line reading Nikita Leonov via GitGitGadget
2020-09-28 20:31   ` [PATCH v2 0/3] Prepare git credential to read input with DOS line endings Junio C Hamano

git@vger.kernel.org list mirror (unofficial, one of many)

This inbox may be cloned and mirrored by anyone:

	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V1 git git/ https://public-inbox.org/git \
		git@vger.kernel.org
	public-inbox-index git

Example config snippet for mirrors.
Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.io/gmane.comp.version-control.git
 note: .onion URLs require Tor: https://www.torproject.org/

code repositories for the project(s) associated with this inbox:

	https://80x24.org/mirrors/git.git

AGPL code for this site: git clone https://public-inbox.org/public-inbox.git