git_signing_key_tmp file does not get cleaned up

[florisvdg]

When signing a Git commit with an SSH key, Git creates two temp files:

• .git_signing_key_tmpXXXXXX containing the public key that should be used for signing
• .git_signing_buffer_tmpXXXXXX containing the payload that needs to be signed

After a successful ssh-keygen invocation, Git should clean up both temp files. However, only the signing buffer file gets properly deleted, but the the signing key file remains.

It's reasonable to think that the signing key file is intentionally kept and reused for consecutive integrations, but that doesn't happen either. A new signing key file is created for each git commit command and never cleaned up by Git:

Gitconfig

[gpg]
	format = ssh
[user]
	signingkey = ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAA<...full SSH pubkey>

Git trace

PS> git commit -S --allow-empty -m "Test"
17:29:01.633560 exec-cmd.c:266          trace: resolved executable dir: C:/Program Files/Git/mingw64/bin
17:29:01.649157 git.c:476               trace: built-in: git commit -S --allow-empty -m Test
17:29:01.649157 run-command.c:668       trace: run_command: ssh-keygen -Y sign -n git -f 'C:\Users\<username>\AppData\Local\Temp/.git_signing_key_tmpWcbfcD' -U 'C:\Users\<username>\AppData\Local\Temp/.git_signing_buffer_tmpbNtry5'
17:29:01.649157 run-command.c:929       trace: start_command: ssh-keygen -Y sign -n git -f 'C:\Users\<username>\AppData\Local\Temp/.git_signing_key_tmpWcbfcD' -U 'C:\Users\<username>\AppData\Local\Temp/.git_signing_buffer_tmpbNtry5'
17:29:01.758616 run-command.c:668       trace: run_command: git maintenance run --auto --no-quiet --detach
17:29:01.758616 run-command.c:929       trace: start_command: git maintenance run --auto --no-quiet --detach
17:29:01.774198 exec-cmd.c:266          trace: resolved executable dir: C:/Program Files/Git/mingw64/libexec/git-core
17:29:01.774198 git.c:476               trace: built-in: git maintenance run --auto --no-quiet --detach
[main e10ec57] Test

Git version

git version 2.48.1.windows.1

[dscho]

Is this behavior specific to Windows, or can you reproduce the same issue in WSL?