0

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
Saqib Ali
  • 11,931
  • 41
  • 133
  • 272

3 Answers3

3

The error you're receiving from GnuPG is because the public key isn't trusted/verified within your keyring. Because your OP stated that your running tests you may want to check out the code within a helper script written for my own experiments, GnuPG_Gen_Key.sh, specifically the functions copied/modded below.

#!/usr/bin/env bash
Var_gnupg_import_key="${1}"
Var_gnupg_import_key_trust="${2}"
Func_import_gnupg_key_edit_trust(){
    _gnupg_import_key="${1:-${Var_gnupg_import_key}}"
    gpg --no-tty --command-fd 0 --edit-key ${_gnupg_import_key} <<EOF
trust
${Var_gnupg_import_key_trust}
quit
EOF
}
Func_import_gnupg_key(){
    _gnupg_import_key="${1:-${Var_gnupg_import_key}}"
    if [ -f "${_gnupg_import_key}" ]; then
        echo "# ${Var_script_name} reports: importing key file [${_gnupg_import_key}]"
        gpg --no-tty --command-fd 0 --import ${_gnupg_import_key} <<EOF
 trust
${Var_gnupg_import_key_trust}
quit
EOF
    else
        _grep_string='not found on keyserver'
        gpg --dry-run --batch --search-keys ${_gnupg_import_key} --keyserver ${Var_gnupg_key_server} | grep -qE "${_grep_string}"
        _exit_status=$?
        if [ "${_exit_status}" != "0" ]; then
            _key_fingerprint="$(gpg --no-tty --batch --dry-run --search-keys ${_gnupg_import_key} | awk '/key /{print $5}' | tail -n1)"
            _key_fingerprint="${_key_fingerprint//,/}"
            if [ "${#_key_fingerprint}" != "0" ]; then
                echo "# ${Var_script_name} reports: importing key [${_key_fingerprint}] from keyserver [${Var_gnupg_key_server}]"
                gpg --keyserver ${Var_gnupg_key_server} --recv-keys ${_key_fingerprint}
                Func_import_gnupg_key_edit_trust "${_gnupg_import_key}"
            else
                echo "# ${Var_script_name} reports: error no public key [${_gnupg_import_key}] as file or on key server [${Var_gnupg_key_server}]"
            fi
        else
            echo "# ${Var_script_name} reports: error no public key [${_gnupg_import_key}] as file or on key server [${Var_gnupg_key_server}]"
        fi
    fi
}

One can either trust the public key with above or use the following command to have GnuPG ignore trust issues.

gpg --armor --always-trust -r 'jdoe@gmail.com' -e myFile.txt -o myFile.txt.gpg

Note I've added the --armor option because the output in the OP looks to have missed that based off the snipped output.

S0AndS0
  • 860
  • 1
  • 7
  • 20
2

You have to add --always-trust to your command:

echo "test" | gpg --batch --yes --always-trust --encrypt --armor -r "mail@example.com"
levi-jcbs
  • 72
  • 4
0

Probably better than using --always-trust is to sign the keys your are relying on once with your private key. Then gpg won't ask again.

Also you encrypted standard input, so the ciphertext will be sent to standard output. In most cases you want to use option --armor to produce ASCII output.

U. Windl
  • 3,480
  • 26
  • 54