From: Junio C Hamano <gitster@pobox.com>
To: "M Hickford via GitGitGadget" <gitgitgadget@gmail.com>
Cc: git@vger.kernel.org, "Jeff King" <peff@peff.net>,
"Dennis Kaarsemaker" <dennis@kaarsemaker.net>,
"Mantas Mikulėnas" <grawity@gmail.com>,
"Javier Roucher Iglesias"
<Javier.Roucher-Iglesias@ensimag.imag.fr>,
"Matthieu Moy" <git@matthieu-moy.fr>,
"M Hickford" <mirth.hickford@gmail.com>
Subject: Re: [PATCH v2] credential/libsecret: support password_expiry_utc
Date: Thu, 04 May 2023 10:42:41 -0700 [thread overview]
Message-ID: <xmqqjzxoj8mm.fsf@gitster.g> (raw)
In-Reply-To: <pull.1469.v2.git.git.1679729764851.gitgitgadget@gmail.com> (M. Hickford via GitGitGadget's message of "Sat, 25 Mar 2023 07:36:04 +0000")
"M Hickford via GitGitGadget" <gitgitgadget@gmail.com> writes:
> From: M Hickford <mirth.hickford@gmail.com>
>
> Signed-off-by: M Hickford <mirth.hickford@gmail.com>
> ---
> diff --git a/contrib/credential/libsecret/git-credential-libsecret.c b/contrib/credential/libsecret/git-credential-libsecret.c
> index 2c5d76d789f..3f2b530db79 100644
> --- a/contrib/credential/libsecret/git-credential-libsecret.c
> +++ b/contrib/credential/libsecret/git-credential-libsecret.c
> @@ -39,6 +39,7 @@ struct credential {
> char *path;
> char *username;
> char *password;
> + char *password_expiry_utc;
> };
>
> #define CREDENTIAL_INIT { 0 }
> @@ -54,6 +55,20 @@ struct credential_operation {
>
> /* ----------------- Secret Service functions ----------------- */
>
> +static const SecretSchema schema = {
> + "org.git.Password",
> + SECRET_SCHEMA_NONE,
> + {
> + { "user", SECRET_SCHEMA_ATTRIBUTE_STRING },
> + { "object", SECRET_SCHEMA_ATTRIBUTE_STRING },
> + { "protocol", SECRET_SCHEMA_ATTRIBUTE_STRING },
> + { "port", SECRET_SCHEMA_ATTRIBUTE_INTEGER },
> + { "server", SECRET_SCHEMA_ATTRIBUTE_STRING },
> + { "password_expiry_utc", SECRET_SCHEMA_ATTRIBUTE_INTEGER },
> + { NULL, 0 },
> + }
> +};
We used to use the bog-standard "COMPAT_NETWORK" but now we are
adding an extra element, and that makes it necessary to define our
own? OK.
> static char *make_label(struct credential *c)
> {
> if (c->port)
> @@ -78,6 +93,9 @@ static GHashTable *make_attr_list(struct credential *c)
> g_hash_table_insert(al, "port", g_strdup_printf("%hu", c->port));
> if (c->path)
> g_hash_table_insert(al, "object", g_strdup(c->path));
> + if (c->password_expiry_utc)
> + g_hash_table_insert(al, "password_expiry_utc",
> + g_strdup(c->password_expiry_utc));
>
> return al;
> }
> @@ -101,9 +119,11 @@ static int keyring_get(struct credential *c)
>
> attributes = make_attr_list(c);
> items = secret_service_search_sync(service,
> - SECRET_SCHEMA_COMPAT_NETWORK,
> + &schema,
> attributes,
> - SECRET_SEARCH_LOAD_SECRETS | SECRET_SEARCH_UNLOCK,
> + SECRET_SEARCH_LOAD_SECRETS | SECRET_SEARCH_UNLOCK |
> + // for backwards compatibility
No // comments please.
> + SECRET_SCHEMA_DONT_MATCH_NAME,
SECRET_SCHEMA_DONT_MATCH_NAME does not seem to be listed as one of
the flags to be used with secret_service_search_sync(),
https://www.manpagez.com/html/libsecret-1/libsecret-1-0.18.6/SecretService.php#secret-service-search-sync
and the only reference to it I found was as a flag to be placed in
the schema.
https://www.manpagez.com/html/libsecret-1/libsecret-1-0.18.6/migrating-schemas.php
https://www.manpagez.com/html/libsecret-1/libsecret-1-0.18.6/libsecret-SecretSchema.php
But I'll take your word for it.
I found nothing unexpected or surprising in the rest of the patch to
this file. They all looked just a fallout of having to store and
retrieve one extra item from the database together with many other
things we already store and retrieve. Cleanly written.
> diff --git a/t/lib-credential.sh b/t/lib-credential.sh
> index 5ea8bc9f1dc..9ebf7eeae48 100644
> --- a/t/lib-credential.sh
> +++ b/t/lib-credential.sh
> @@ -43,6 +43,7 @@ helper_test_clean() {
> reject $1 https example.com store-user
> reject $1 https example.com user1
> reject $1 https example.com user2
> + reject $1 https example.com user3
> reject $1 http path.tld user
> reject $1 https timeout.tld user
> reject $1 https sso.tld
> @@ -298,6 +299,35 @@ helper_test_timeout() {
> '
> }
>
> +helper_test_password_expiry_utc() {
> + HELPER=$1
> +
> + test_expect_success "helper ($HELPER) stores password_expiry_utc" '
> + check approve $HELPER <<-\EOF
> + protocol=https
> + host=example.com
> + username=user3
> + password=pass
> + password_expiry_utc=9999999999
> + EOF
> + '
>
> + test_expect_success "helper ($HELPER) gets password_expiry_utc" '
> + check fill $HELPER <<-\EOF
> + protocol=https
> + host=example.com
> + username=user3
> + --
> + protocol=https
> + host=example.com
> + username=user3
> + password=pass
> + password_expiry_utc=9999999999
> + --
> + EOF
> + '
> +}
> +
Is any random number usable for this test, or is there some
constraints (like, "it cannot be too small to be a timestamp in the
past, because the entry will be expired immediately")? If there is
some constraint like that, is it a good idea to also test that
(like, "make sure an entry with expiry already happened is
rejected")?
Thanks.
next prev parent reply other threads:[~2023-05-04 17:42 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-14 21:32 [PATCH] credential/libsecret: support password_expiry_utc M Hickford via GitGitGadget
2023-03-25 7:36 ` [PATCH v2] " M Hickford via GitGitGadget
2023-05-04 17:42 ` Junio C Hamano [this message]
2023-05-05 7:00 ` M Hickford
2023-05-05 7:04 ` [PATCH v3] " M Hickford via GitGitGadget
2023-05-15 10:50 ` M Hickford
2023-05-15 18:14 ` Junio C Hamano
2023-05-16 8:03 ` M Hickford
2023-05-16 16:10 ` Junio C Hamano
2023-05-17 6:55 ` [PATCH v4] credential/libsecret: store new attributes M Hickford via GitGitGadget
2023-06-16 19:55 ` [PATCH v5] " M Hickford via GitGitGadget
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=xmqqjzxoj8mm.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=Javier.Roucher-Iglesias@ensimag.imag.fr \
--cc=dennis@kaarsemaker.net \
--cc=git@matthieu-moy.fr \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@gmail.com \
--cc=grawity@gmail.com \
--cc=mirth.hickford@gmail.com \
--cc=peff@peff.net \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.