How to use Gnupg's passphrase-fd argument?

后端 未结 4 746
广开言路
广开言路 2020-12-23 20:42

I would like to use GnuPG´s decrypt command without any user interation. The script\'s --passphrase-fd argument seems exactly what I need. But I do

4条回答
  •  暖寄归人
    2020-12-23 21:13

    As I've had to recently figure this out myself I thought it might be worth chiming in.

    The answer by kylehuff is very good if you're decryping files, however, if you've need of input/output redirection, such as piping, here's an example of using a non-0 file descriptor to pass the passphrase.

    #!/usr/bin/env bash
    # Set some variables for easy modding
    Var_fd='9'
    Var_pass_location="/path/to/passphrase.file"
    Var_gpg_decrypt_opts="--passphrase-fd ${Var_fd} --decrypt"
    Var_output_location="out.txt"
    Arr_string=( "$@" )
    # Open file descriptor and shove the passphrase file into it
    exec ${Var_fd}<${Var_pass_location}
    # Pipe input array though gpg and append to output file
    cat <<<"${Arr_string[*]}" | $(which gpg) ${Var_gpg_decrypt_opts} >> ${Var_output_location}
    # Do not forget to close the file descriptor
    exec ${Var_fd}>&-
    

    Do be warned, outside of special use cases, that saving your private keys passphrase is generally seen as a bad idea or bad security practice. -Also please don't forget to close the descriptor when finished so that your passphrase isn't accessible via that method anymore.- Often I've seen advised in these use cases to use specifically non-passphrase protected keys but that's totally your choose. If you like the above code then you may want to also checkout the script I debugged for key generation either unattended or attended because it covers even less commonly used gpg file descriptor options.

    Edits/updates

    So I've been debugging the bulk decryption operations and have evidence to show that file descriptors seem to close automatically or perhaps it's auto closed by GnuPG. Check build 152 all the way at the bottom of the raw logs, just before diff checks, you'll find that the first block of encrypted data ate the passphrase leaving the next two blocks of data without a valid passphrase. The related scripts in this operation are ; first the script_decrypt.sh build script sets the test key's passphrase to file descriptor 9 as shown in above examples, then the Helper script is called such that it'll make use of that file descriptor... it's a funky use case but the moral of the story seems to be that what ever bulk decryption operations you plan to implement with GnuPG file descriptors will likely need to follow the steps outlined above as a whole function to properly have the file descriptors reopened. I'll be rewriting the helper script over the next few pushes so check the Travis-CI build logs greater than 152 to find if I've a solution to where file descriptors get closed...

    ... so that only took two tries to get things working, see the difference in build 154 both the encrypted file and raw input log match. As hypothesised the file descriptors get dumped after first usage by either GnuPG or a sub shell, thus the passphrase needs to be assigned before every decrypt command for bulk decryption to happen.

    Hope this was valuable to y'all.

提交回复
热议问题