From: Jeff King <peff@peff.net>
To: M Hickford via GitGitGadget <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org,
Matthew John Cheetham <mjcheetham@outlook.com>,
M Hickford <mirth.hickford@gmail.com>
Subject: Re: [PATCH v3 1/2] credential: avoid erasing distinct password
Date: Thu, 15 Jun 2023 03:08:09 -0400 [thread overview]
Message-ID: <20230615070809.GA1460739@coredump.intra.peff.net> (raw)
In-Reply-To: <df3c8a15bf8ef3258ed6959568cf4cfd1042f71d.1686809004.git.gitgitgadget@gmail.com>
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
next prev parent reply other threads:[~2023-06-15 7:11 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-14 11:23 [PATCH 0/2] credential: improvements to erase in helpers M Hickford via GitGitGadget
2023-06-14 11:23 ` [PATCH 1/2] credential: avoid erasing distinct password M Hickford via GitGitGadget
2023-06-14 11:23 ` [PATCH 2/2] credential: erase all matching credentials M Hickford via GitGitGadget
2023-06-14 16:00 ` Junio C Hamano
2023-06-14 21:35 ` M Hickford
2023-06-14 21:40 ` [PATCH v2 0/2] credential: improvements to erase in helpers M Hickford via GitGitGadget
2023-06-14 21:40 ` [PATCH v2 1/2] credential: avoid erasing distinct password M Hickford via GitGitGadget
2023-06-14 22:43 ` Jeff King
2023-06-15 4:51 ` M Hickford
2023-06-14 21:40 ` [PATCH v2 2/2] credential: erase all matching credentials M Hickford via GitGitGadget
2023-06-14 22:51 ` Jeff King
2023-06-15 4:57 ` M Hickford
2023-06-14 21:56 ` [PATCH v2 0/2] credential: improvements to erase in helpers Junio C Hamano
2023-06-14 22:51 ` Jeff King
2023-06-15 6:03 ` [PATCH v3 " M Hickford via GitGitGadget
2023-06-15 6:03 ` [PATCH v3 1/2] credential: avoid erasing distinct password M Hickford via GitGitGadget
2023-06-15 7:08 ` Jeff King [this message]
2023-06-15 6:03 ` [PATCH v3 2/2] credential: erase all matching credentials M Hickford via GitGitGadget
2023-06-15 7:09 ` Jeff King
2023-06-15 19:19 ` [PATCH v4 0/2] credential: improvements to erase in helpers M Hickford via GitGitGadget
2023-06-15 19:19 ` [PATCH v4 1/2] credential: avoid erasing distinct password M Hickford via GitGitGadget
2023-06-15 19:19 ` [PATCH v4 2/2] credential: erase all matching credentials M Hickford via GitGitGadget
2023-06-15 21:09 ` [PATCH v4 0/2] credential: improvements to erase in helpers Junio C Hamano
2023-06-15 21:21 ` Jeff King
2023-06-15 21:52 ` Junio C Hamano
2023-06-16 16:54 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20230615070809.GA1460739@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=mirth.hickford@gmail.com \
--cc=mjcheetham@outlook.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).