From: Junio C Hamano <gitster@pobox.com>
To: M Hickford <mirth.hickford@gmail.com>
Cc: M Hickford via GitGitGadget <gitgitgadget@gmail.com>,
git@vger.kernel.org, Jeff King <peff@peff.net>
Subject: Re: [PATCH v3] credential/libsecret: support password_expiry_utc
Date: Tue, 16 May 2023 09:10:33 -0700 [thread overview]
Message-ID: <xmqq4jocw93a.fsf@gitster.g> (raw)
In-Reply-To: <CAGJzqsn_Jmr3x0tj3U7QRD3eGMzWwr3RR1-O3_YzFCMCU7u+eQ@mail.gmail.com> (M. Hickford's message of "Tue, 16 May 2023 09:03:51 +0100")
M Hickford <mirth.hickford@gmail.com> writes:
> Yes, I think that would work nicely. A format such as that below would
> be backwards compatible (passwords already can't contain newlines) and
> self explanatory to any curious user browsing their secret store. I
> already have a draft that works much like this. I'll prepare a patch
> v4.
>
> 7d7b554
> password_expiry_utc=1684179877
> oauth_refresh_token=be8a9aa3
>
> Is the secret store ever shared with other applications such as a web
> browser? If so, sharing is already broken, because popular Git hosts
> such as GitHub and GitLab expect different passwords for web login and
> Git authentication (OAuth token or personal access token).
It probably is a good argument. We do not have to worry about
interoperating with browsers and their authentication with Git
hosting sites. And the "newline can be used to add extra pieces of
information" is a good trick ;-)
> A solution
> could be to introduce our own libsecret schema (as in the current
> patch) instead of continuing to use SECRET_SCHEMA_COMPAT_NETWORK
> potentially shared with other apps. I'm not sure whether that's
> worthwhile in this patch. I defer to you.
It may depend on what other Git GUI frontends may want to do. If
there is no precedent and you are the pioneer, then using our own
would be perfectly fine and we can let others also read from us if
they want to; I presume that it would not prevent us from doing so
even if did not use COMPAT_NETWORK (which gnome dev document even
discourages of its use in new applications anyway).
Thanks.
next prev parent reply other threads:[~2023-05-16 16:12 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
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 [this message]
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=xmqq4jocw93a.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=gitgitgadget@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 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 read-only IMAP folder(s) and NNTP newsgroup(s).