From: Junio C Hamano <gitster@pobox.com>
To: Fabian Stelzer <fs@gigacodes.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] ssh signing: support non ssh-* keytypes
Date: Wed, 17 Nov 2021 19:09:08 -0800 [thread overview]
Message-ID: <xmqq4k8a2m97.fsf@gitster.g> (raw)
In-Reply-To: 20211117162727.650857-1-fs@gigacodes.de
Fabian Stelzer <fs@gigacodes.de> writes:
> +/* Determines wether key contains a literal ssh key or a path to a file */
> +static int is_literal_ssh_key(const char *key) {
> + return (
> + starts_with(key, "ssh-") ||
> + starts_with(key, "ecdsa-") ||
> + starts_with(key, "sk-ssh-") ||
> + starts_with(key, "sk-ecdsa-")
> + );
> +}
A more forward looking thing you could do is to
(1) grandfather the convention "any string that begins with 'ssh-'
is taken as a ssh literal key".
(2) refrain from spreading such an unstructured mess by picking a
reserved prefix, say "ssh-key::" and have all other kinds of
ssh keys use the convention.
making the above function look more like
static int is_literal_ssh_key(const char *string, const char **key)
{
if (skip_prefix(string, "ssh-key::", key)
return 1;
if (starts_with(string, "ssh-")) {
key = string;
return 1;
}
return 0;
}
so that the caller can extract the literal key from the string that
specifies either the literal key or path to the file. This will
futureproof us in two axis. When SSH adds types of keys using new
algo, we do not have to add it to is_literal_ssh_key() function.
Also when another crypto suite other than GPG and SSH comes, we
won't repeat the "bare 'ssh-' prefix is reserved by ssh, and
different kind in the same suite may have to consume more reserved
prefixes" mistake---it would make it more natural for us to pick
"literal keys from any variant of that new FOO crypto suite are
written with 'foo-key::' prefix" if we did so right now. It would
have been better if we didn't have to do the grandfathering, but I
am assuming that the ship has already sailed?
> @@ -719,7 +729,7 @@ static char *get_ssh_key_fingerprint(const char *signing_key)
> * With SSH Signing this can contain a filename or a public key
> * For textual representation we usually want a fingerprint
> */
> - if (starts_with(signing_key, "ssh-")) {
> + if (is_literal_ssh_key(signing_key)) {
> strvec_pushl(&ssh_keygen.args, "ssh-keygen", "-lf", "-", NULL);
> ret = pipe_command(&ssh_keygen, signing_key,
> strlen(signing_key), &fingerprint_stdout, 0,
This part needs a bit of adjustment if we go the
"is_literal_ssh_key() is not just a boolean but is used to strip the
prefix to signal the kind of key" route, but the necessary
adjustment should be trivial.
next prev parent reply other threads:[~2021-11-18 3:09 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-17 16:27 [PATCH] ssh signing: support non ssh-* keytypes Fabian Stelzer
2021-11-17 17:51 ` Taylor Blau
2021-11-18 3:09 ` Junio C Hamano [this message]
2021-11-18 6:39 ` Junio C Hamano
2021-11-18 15:16 ` Fabian Stelzer
2021-11-18 17:14 ` [PATCH v2 1/2] " Fabian Stelzer
2021-11-18 17:14 ` [PATCH v2 2/2] ssh signing: make sign/amend test more resilient Fabian Stelzer
2021-11-18 22:14 ` [PATCH v2 1/2] ssh signing: support non ssh-* keytypes Eric Sunshine
2021-11-19 9:05 ` Fabian Stelzer
2021-11-19 15:07 ` [PATCH v3 0/2] " Fabian Stelzer
2021-11-19 15:07 ` [PATCH v3 1/2] " Fabian Stelzer
2021-11-19 15:07 ` [PATCH v3 2/2] ssh signing: make sign/amend test more resilient Fabian Stelzer
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=xmqq4k8a2m97.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=fs@gigacodes.de \
--cc=git@vger.kernel.org \
/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).