For verifying builds of Renderdoc using the publisher's public key, verifying the Linux binary tarball works as expected; I run gpg --import ./baldurk-pubkey.asc and then gpg --verify renderdoc_1.18.tar.gz.sig renderdoc_1.18.tar.gz and then I receive the following output:
gpg: Signature made Tue Jan 25 07:25:56 2022 MST
gpg: using RSA key 1B039DB9A4718A2D699DE031AC612C3120C34695
gpg: Good signature from "Baldur Karlsson <[email protected]>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 1B03 9DB9 A471 8A2D 699D E031 AC61 2C31 20C3 4695
However, when I try to do the same process for the Windows 64-bit portable zip, i.e. gpg --verify RenderDoc_1.18_64.zip.sig RenderDoc_1.18_64.zip I receive the following output instead:
gpg: Signature made Tue Jan 25 08:01:06 2022 MST
gpg: using RSA key EC0F4688931695D3BCF0D10FB93B9B66E68BA2E9
gpg: Can't check signature: No public key
I receive similar output if I attempt to pass in the extracted qrenderdoc.exe as the second argument instead of the .zip itself.
I understand that the Windows executables have their own digital signatures; if I right-click qrenderdoc.exe, go to "Properties", and then go to the "Digital Signatures" tab, there is a signature by the same publisher. But I am confused as to what purpose the Windows .sig files serve or how to use them. I'm assuming there must be a correct way to do this, or else the sig files would not be provided, but I do not know what that way would be.
OK, I can sort of understand the downvote to my question. Clearly, as the output to the command for the .zip.sig says, it was signed with a different RSA key. I assumed that, since the Renderdoc website makes no mention of another key and nobody else online mentioned any issues with the Renderdoc signatures, then clearly there was an obvious way to find/add said key that I was missing. But after asking the developer, it turns out they changed build systems at some point and a different key was being used, and I guess I was just the first one to notice or report the problem. I can see now that this probably should have been my first assumption; apologies for the unnecessary question.
In the miniscule chance another Renderdoc user stumbles across this: According to the developer, subsequent builds (so anything above the current v1.18) will be signed with the correct key.