<div>I've been working on a scheme for signing binary images that we ship out to various remote systems. The remote system expects the file to be both encrypted and signed, but there seem to be some corner cases:<br></div><div><br></div><div>(1) If a file is signed but the signature is incorrect, 'gpg2 -d' returns a non-zero status code, so the remote script knows not to trust the file, but if the file carries no signature at all, then decryption succeeds and there is no indication to a script that there was not a valid signature.This opens a window for an attacker to send a fine that is properly encrypted but not signed at all, and it looks like gpg2 will not catch that case. Is there an option I can give in addition to -d that REQUIRES the file to be signed? I realize you can verify a detached signature as a secondary step but I was hoping there would be a way to combine everything into one command.<br></div><div>(2) If a file is signed and the remote script has the signer's public key, then a --verify operation will succeed. The trouble is, what if the file is signed by some signature in the remote script's keyring other than the expected code signing key? Is there an option that can be given to --verify (or along with -d, if there's a solution to (1)) that can specify the exact signing key (or keys) required? I tried using -u with --verify, and although no error was generated, the parameter was ignored.<br></div><div>(3) If a file is both encrypted and signed, is there a way to merely verify the signature other than to include a detached signature? Right now, using --verify on a single file that was encrypted/signed with -es just gives "gpg: verify signatures failed: Unexpected error." Is there a way around that, so I don't need to use a detached signature?<br></div><div><br></div><div>Thanks!<br></div>