I'm writing a script that uses gpg
to encrypt a file. During testing/experimentation with gpg
from the command-line, I found some odd behavior. This works perfectly fine:
$ cat myFile.txt | gpg --encrypt -r 'jdoe@gmail.com'
gpg: B2D17635: There is no assurance this key belongs to the named user
pub 4096R/B2D17635 2016-01-31 John Doe (I am now a real person.) <jdoe@gmail.com>
Primary key fingerprint: B17F 98BA 1DA9 3FE1 A08F 1443 509D 87ED 32AF 2078
Subkey fingerprint: BB63 42DA 8FAD 194A E1C9 1F6D 39BA 73B9 B2D1 7635
It is NOT certain that the key belongs to the person named
in the user ID. If you *really* know what you are doing,
you may answer the next question with yes.
Use this key anyway? (y/N) y
�
Nϴ��[�mDZ.@�Bc���J������z�{p���%
<GIBBERISH SNIPPED>
i�)��/&N��t�Z�8�#�I<�Bq�!�K?�vQ�I�H6&+��(
But I don’t like that because I interactively had to type ‘y’. I would like it to assume “yes” and do the encryption without requiring any interactivity. So I ran the following command with the --batch
and --yes
switches. Why did it fail?
$ cat myFile.txt | gpg --encrypt --batch --yes -r 'jdoe@gmail.com'
gpg: B2D17635: There is no assurance this key belongs to the named user
gpg: [stdin]: encryption failed: unusable public key