Re: Error / feature-request: Signing git commits with SSH hardware key

[Nicolas Graves <ngraves@ngraves.fr>]

>> error: Couldn't load public key sk-ssh-ed25519@openssh.com AAAAG[..]zaDo=: No such file or directory?
>
Sorry, I still do have this error, even though the previous one
disappeared (it verified a commit signed byb another key) and my
configuration is OK.

No such file or directory would indicate I don't own the key. I've
verified I have the key on my Yubikey5C, in the directory ~/.ssh with
the right condition, and additionnaly I've imported it in ssh-agent with
ssh-add.

Using the GIT_TRACE=2 env variable, I get this:
08:32:41.916712 git.c:460               trace: built-in: git commit -m test
08:32:41.917380 run-command.c:655       trace: run_command: ssh-keygen -Y sign -n git -f 'sk-ssh-ed25519@openssh.com AAAAG[...]zaDo=' /tmp/.git_signing_buffer_tmp6Dc0Mx

The ssh-keygen manual indicates the following:

-Y sign
             Cryptographically sign a file or some data using a SSH key.  When
             signing, ssh-keygen accepts zero or more files to sign on the
             command-line - if no files are specified then ssh-keygen will
             sign data presented on standard input.  Signatures are written to
             the path of the input file with “.sig” appended, or to standard
             output if the message to be signed was read from standard input.

             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).  An additional signature name‐
             space, used to prevent signature confusion across different do‐
             mains of use (e.g. file signing vs email signing) must be pro‐
             vided via the -n flag.  Namespaces are arbitrary strings, and may
             include: “file” for file signing, “email” for email signing.  For
             custom uses, it is recommended to use names following a NAME‐
             SPACE@YOUR.DOMAIN pattern to generate unambiguous namespaces.

Running ssh-add -L, I can confirm that the private half is available via
ssh-agent.

I've also check that the error doesn't come from the missing input file (used to
sign), here /tmp/.git_signing_buffer_tmp6Dc0Mx . Re-running the
ssh-keygen command with a mock file fails with the same error.

I don't really know where to investigate next. What I get is that the
error probably comes from ssh (should I report it there? The problem
feels isolated now that I know which command fails). I may try to
update openssh to v9, but since I'm using guix that might be quick as
well as tedious.

-- 
Best regards,
Nicolas Graves