git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Fabian Stelzer <fs@gigacodes.de>
To: phillip.wood@dunelm.org.uk
Cc: Adam Szkoda <adaszko@gmail.com>,
	Adam Szkoda via GitGitGadget <gitgitgadget@gmail.com>,
	git@vger.kernel.org
Subject: Re: [PATCH] ssh signing: better error message when key not in agent
Date: Fri, 20 Jan 2023 10:03:31 +0100	[thread overview]
Message-ID: <20230120090331.37dxkko6bgxbjae7@fs> (raw)
In-Reply-To: <55282dec-825f-8c4b-1fb0-6e26ec326db1@dunelm.org.uk>

On 18.01.2023 16:29, Phillip Wood wrote:
>Hi Adam
>
>I've cc'd Fabian who knows more about the ssh signing code that I do.
>
>On 18/01/2023 15:28, Adam Szkoda wrote:
>>Hi Phillip,
>>
>>Good point!  My first thought is to try doing a stat() syscall on the
>>path from 'user.signingKey' to see if it exists and if not, treat it
>>as a public key (and pass the -U option).  If that sounds reasonable,
>>I can update the patch.
>
>My reading of the documentation is that user.signingKey may point to a 
>public or private key so I'm not sure how stat()ing would help. 
>Looking at the code in sign_buffer_ssh() we have a function 
>is_literal_ssh_key() that checks if the config value is a public key. 
>When the user passes the path to a key we could read the file check 
>use is_literal_ssh_key() to check if it is a public key (or possibly 
>just check if the file begins with "ssh-"). Fabian - does that sound 
>reasonable?

Hi,
I have encountered the mentioned problem before as well and tried to fix it 
but did not find a good / reasonable way to do so. Git just passes the 
user.signingKey to ssh-keygen which states:
`The key used for signing is specified using the -f option and may refer to 
either a private key, or a public key with the private half available via 
ssh-agent(1)`

I don't think it's a good idea for git to parse the key and try to determine 
if it's public or private. The fix should probably be in openssh (different 
error message) but when looking into it last time i remember that the logic 
for using the key is quite deeply embedded into the ssh code and not easily 
adjusted for the signing use case. At the moment I don't have the time to 
look into it but the openssh code for signing is quite readable so feel free 
to give it a try. Maybe you find a good way.

Best regards,
Fabian

>
>Best Wishes
>
>Phillip
>
>>Best
>>— Adam
>>
>>
>>On Wed, Jan 18, 2023 at 3:34 PM Phillip Wood <phillip.wood123@gmail.com> wrote:
>>>
>>>On 18/01/2023 11:10, Phillip Wood wrote:
>>>>>the agent [1].  A fix is scheduled to be released in OpenSSH 9.1. All
>>>>>that
>>>>>needs to be done is to pass an additional backward-compatible option
>>>>>-U to
>>>>>'ssh-keygen -Y sign' call.  With '-U', ssh-keygen always interprets
>>>>>the file
>>>>>as public key and expects to find the private key in the agent.
>>>>
>>>>The documentation for user.signingKey says
>>>>
>>>>   If gpg.format is set to ssh this can contain the path to either your
>>>>private ssh key or the public key when ssh-agent is used.
>>>>
>>>>If I've understood correctly passing -U will prevent users from setting
>>>>this to a private key.
>>>
>>>If there is an easy way to tell if the user has given us a public key
>>>then we could pass "-U" in that case.
>>>
>>>Best Wishes
>>>
>>>Phillip

  reply	other threads:[~2023-01-20  9:03 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-18  8:17 [PATCH] ssh signing: better error message when key not in agent Adam Szkoda via GitGitGadget
2023-01-18 11:10 ` Phillip Wood
2023-01-18 14:34   ` Phillip Wood
2023-01-18 15:28     ` Adam Szkoda
2023-01-18 16:29       ` Phillip Wood
2023-01-20  9:03         ` Fabian Stelzer [this message]
2023-01-23  9:33           ` Phillip Wood
2023-01-23 10:02             ` Fabian Stelzer
2023-01-23 16:17               ` Adam Szkoda
2023-01-24 15:26 ` [PATCH v2] " Adam Szkoda via GitGitGadget
2023-01-24 17:52   ` Junio C Hamano
2023-01-25 12:46     ` Adam Szkoda
2023-01-25 17:04       ` Junio C Hamano
2023-01-25 17:17       ` Junio C Hamano
2023-01-25 21:42       ` Eric Sunshine
2023-01-25 22:22         ` Junio C Hamano
2023-02-15  1:22           ` Eric Sunshine
2023-01-25 12:40   ` [PATCH v3] " Adam Szkoda 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230120090331.37dxkko6bgxbjae7@fs \
    --to=fs@gigacodes.de \
    --cc=adaszko@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitgitgadget@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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).