| Commit message (Collapse) | Author | Age |
|
|
|
|
|
|
|
|
|
| |
Decrypt ciphertext using gpgsm if the user has indicated that it's ok.
This includes a new element in the test suite, which uses secret key
material from https://www.ietf.org/id/draft-dkg-lamps-samples-01.html
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Acked-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
| |
This allows the user to avoid being affected by any future change in
the default.
Signed-off-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turns out that type=bool doesn't really do what we want it to do (see
https://bugs.python.org/issue37564), and there is no built-in easy
answer for argparse to accept a boolean value sensibly
(e.g. type='bool', which might be able to handle "yes" and "no" and
"1" and "0" and "on" and "off" as well as "true" and "false", etc)
So rather than implement all of that here, we'll just have
--use-gpg-agent as a simple flag. This is an API change, but the
previous API has only been out for a few days, and the tool is
documented for interactive use.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
|
|
|
| |
RFC 3156 documents PGP/MIME structural assumptions
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Acked-by: Sean Whitton <spwhitton@spwhitton.name>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In some cases, the user may want to try to use their own GnuPG secret
keys to decrypt encrypted parts of the message.
By default it is disabled so that we aren't accidentally triggering
the use of user secret key material.
Note that gpg(1) says:
It is highly recommended to use [--batch] along with the options
--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).
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
| |
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add simple decryption capability for email-print-mime-structure, so
that it can do stuff like this:
$ email-print-mime-structure --pgpkey alice@openpgp.example.sec.asc < msg.eml
└┬╴multipart/encrypted 2190 bytes
├─╴application/pgp-encrypted 11 bytes
└─╴application/octet-stream 1613 bytes
↧ (decrypts to)
└─╴text/plain 425 bytes
$
At the moment, it only works with keys that can be found in the
filesystem, and when the pgpy module is installed.
Possible future work:
- try using gpg to do the decryption from whatever gpg's system
capabilities are
I've added python3-pgpy to the list of Recommends, since it is not a
hard dependency.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
|
|
|
|
|
|
| |
This adds a -h and --help option, which is currently pretty useless.
But the argparse will become useful shortly.
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|
|
Signed-off-by: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
|