go-gitea/gitea

SSH key verification section in the web UI shows incorrect Windows commands

Opened this issue · 5 comments

Description

On Windows the key verification fails because an incorrect command is shown in the key upload section.
Same thing for pgp keys, but I can't solve it in this case.

Example below:

Wrong:
echo -n 'f3f9b8c0f7d4d52810a07f9f28df3e876d30079cdf67897996365fcf9ac0eec4' | ssh-keygen -Y sign -n gitea -f /path_to_PrivateKey_or_RelatedPublicKey

Correct:
echo f3f9b8c0f7d4d52810a07f9f28df3e876d30079cdf67897996365fcf9ac0eec4| ssh-keygen -Y sign -n gitea -f /path_to_PrivateKey_or_RelatedPublicKey

The problem appears to be that Windows treats the quotes and the trailing space before the pipe as part of the token. If you remove -n, the quotes and the space, the verification succeeds.

Screenshots

Image

Gitea Version

1.24.5

Can you reproduce the bug on the Gitea demo site?

Yes

Operating System

Windows 10 22H2 (19045.6332)

Browser Version

Firefox 142.0.1 (64 bit

Hi @wxiaoguang
With those commands you get the exact same error.
I tried them all and the only one that works without returning an error is the one I shared

Same problem on the PGP key:

Image

But in this case nothing works

Image

These commands are from Windows users: enhancement: add additional command hints for PowerShell & CMD (#33548)

Can you figure why they are wrong?

echo -n is for POSIX echo command, its prompt shouldn't be changed.


ps: I don't use Windows for development, so I have no idea about how to "fix" the prompts. Feel free to open a PR to fix the Windows commands if you got the correct commands.

The correct command for the ssh key:

echo f3f9b8c0f7d4d52810a07f9f28df3e876d30079cdf67897996365fcf9ac0eec4| ssh-keygen -Y sign -n gitea -f /path_to_PrivateKey_or_RelatedPublicKey

No spaces, no quotes and works
Before making a pull request I would also like to understand how to solve the PGP verification

Ok, I figured out what happens with the PGP signature.
If on Windows you run, for example:

echo -n "42423d54c47e967870e0be184ed6d262dc7ce29e87fb1f0a628843e021504b85" > tmp.txt

You end up with a file containing:

-n "42423d54c47e967870e0be184ed6d262dc7ce29e87fb1f0a628843e021504b85"

which is basically what it tries to use as the token, and obviously that's wrong.

I solved it by creating a file, putting the correct token inside, and then running:

gpg --armor --default-key CORRECTKEYID --detach-sign tmp.txt

This will generate tmp.txt.asc.
Opening it with Notepad++ to fully respect the encoding, I copied the signature, and it was accepted.
The problem is Windows and how it handles strings in certain cases, next time I'll verify it by changing the value in the database; it'll be faster 😂