Hello,

On Fri 08 Nov 2019 at 09:03AM -05, Daniel Kahn Gillmor wrote:

> On Fri 2019-11-08 02:10:48 -0500, Daniel Kahn Gillmor wrote:
>> +                out:subprocess.CompletedProcess[bytes] = 
>> subprocess.run(['gpg', '--decrypt'],
>> +                                                                        
>> stdin=inp,
>> +                                                                        
>> capture_output=True)
>
> sigh.  this line should have the '--batch' option added between 'gpg'
> and its command '--decrypt'.  I can send you a revised patch, or you can
> feel free to fix it up yourself when applying.  let me know if you'd
> prefer a revised patch.

I've sent you other comments so please add this change to your revised
series.

(Another option would have been to send a "[PATCH 3/2] fixup! ..." patch
which would have signalled to me that it should just be folded into the
2/2 patch.  But what you did was certainly okay too!)

> PS gpg(1) says:
>
>        --batch
>        --no-batch
>               Use  batch  mode.  Never ask, do not allow interactive commands.
>               --no-batch disables this option.  Note that even with a filename
>               given  on  the  command  line, gpg might still need to read from
>               STDIN (in particular if gpg figures that the input is a detached
>               signature  and no data file has been specified).  Thus if you do
>               not want to feed data via STDIN, you  should  connect  STDIN  to
>               g‘/dev/null’.
>
>               It  is  highly recommended to use this option along with the op‐
>               tions --status-fd and --with-colons for any  unattended  use  of
>               gpg.
>
> I am deliberately choosing to not use either --status-fd or
> --with-colons for email-print-mime-structure.
>
> I'm not using --with-colons because there is no output from GnuPG that
> we expect to be machine-readable -- we're just looking for the cleartext
> of whatever ciphertext is in the message part.
>
> I'm not using --status-fd because there is nothing actionable we can do
> with GnuPG status messages, and asking for them would require switching
> from subprocess.run to subprocess.Popen to take advantage of the
> pass_fds argument, which in turn would make the script only work in a
> POSIX environment (i believe, but have not tested, that the script can
> currently be used on Windows).

This makes sense to me.  One possible advantage of --status-fd would be
that we could be more confident gpg will never output anything except
the cleartext to our script, but for a script designed to be used only
interactively, that's not a large advantage.

-- 
Sean Whitton

Attachment: signature.asc
Description: PGP signature

Reply via email to