Re: [PATCH v3 1/2] credential: avoid erasing distinct password

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, Jun 15, 2023 at 06:03:23AM +0000, M Hickford via GitGitGadget wrote:

> @@ -151,14 +151,14 @@ static void serve_one_client(FILE *in, FILE *out)
>  		exit(0);
>  	}
>  	else if (!strcmp(action.buf, "erase"))
> -		remove_credential(&c);
> +		remove_credential(&c, 1);
>  	else if (!strcmp(action.buf, "store")) {
>  		if (timeout < 0)
>  			warning("cache client didn't specify a timeout");
>  		else if (!c.username || !c.password)
>  			warning("cache client gave us a partial credential");
>  		else {
> -			remove_credential(&c);
> +			remove_credential(&c, 0);
>  			cache_credential(&c, timeout);
>  		}
>  	}

Great, this hunk fixes the overwrite problem from the previous round.
All of the credential-cache bits look good to me.

> @@ -29,8 +30,8 @@ static int parse_credential_file(const char *fn,
>  
>  	while (strbuf_getline_lf(&line, fh) != EOF) {
>  		if (!credential_from_url_gently(&entry, line.buf, 1) &&
> -		    entry.username && entry.password &&
> -		    credential_match(c, &entry)) {
> +			entry.username && entry.password &&
> +			credential_match(c, &entry, match_password)) {
>  			found_credential = 1;
>  			if (match_cb) {
>  				match_cb(&entry);

This hunk is from credential-store. I think the code change is doing the
right thing, but the modified indentation is wrong (we'd usually do a
4-space indentation to line up the conditions; doing a full tab confuses
the conditions with the actual body).

> diff --git a/credential.c b/credential.c
> index 023b59d5711..9157ff0865e 100644
> --- a/credential.c
> +++ b/credential.c
> @@ -33,13 +33,14 @@ void credential_clear(struct credential *c)
>  }
>  
>  int credential_match(const struct credential *want,
> -		     const struct credential *have)
> +		     const struct credential *have, int match_password)
>  {
>  #define CHECK(x) (!want->x || (have->x && !strcmp(want->x, have->x)))
>  	return CHECK(protocol) &&
> -	       CHECK(host) &&
> -	       CHECK(path) &&
> -	       CHECK(username);
> +		CHECK(host) &&
> +		CHECK(path) &&
> +		CHECK(username) &&
> +		(!match_password || CHECK(password));
>  #undef CHECK
>  }

The indentation here seemed funny to me, too, though I think it's a
matter of taste (indent a tab versus line up with the seven chars of
"return ". I'd have a slight preference to leave it as-is, just because
it makes the diff noisier, but I'm OK with it either way.

> diff --git a/t/lib-credential.sh b/t/lib-credential.sh
> index f1ab92ba35c..7b4fdd011d7 100644
> --- a/t/lib-credential.sh
> +++ b/t/lib-credential.sh
> @@ -44,6 +44,8 @@ helper_test_clean() {
>  	reject $1 https example.com user1
>  	reject $1 https example.com user2
>  	reject $1 https example.com user4
> +	reject $1 https example.com user5
> +	reject $1 https example.com user8
>  	reject $1 http path.tld user
>  	reject $1 https timeout.tld user
>  	reject $1 https sso.tld

This is a funny gap to have (I realize it is because you use 6-7 in the
next patch, but usually we'd try to do things in order and rebase
downstream patches as appropriate). Doubly funny here is that the test
for "8" comes before "5". That's not wrong from a code/testing
standpoint, but it may make the script harder to read or modify later
on.

Maybe it would be easier to read if we gave these users non-numeric
names that match how we will use them. E.g., can we call user8
user-overwrite or something? That makes the intention obvious, and then
we do not have to worry about maintaining ordering constraints.

> @@ -167,6 +169,49 @@ helper_test() {
>  		EOF
>  	'
>  
> +	test_expect_success "helper ($HELPER) overwrites on store" '
> [...]

Great, thank you for adding a test for this case. The test itself looks
good to me.

> @@ -221,6 +266,31 @@ helper_test() {
>  		EOF
>  	'
>  
> +	test_expect_success "helper ($HELPER) does not erase a password distinct from input" '
> [...]

And this one continues to look good. I think the username could be
"user-distinct-pass" or something if we wanted to go with
human-understandable ones.

-Peff



[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux