This can be really handy when using vim as an external editor
for a program (via temporary files) that you'd like to be able to
encrypt based on the temp file's name (for example, when using
vim as an external editor for Notational Velocity).
Previously, only a contiguous block of uids would be presented to the
user when trying to disambiguate a key. This happened because a key may
have other fields interspersed among the uids, like UAT.
Signed-off-by: James McCoy <vega.james@gmail.com>
This is a step towards reporting keys that aren't valid for encryption
instead of just ignoring them.
Signed-off-by: James McCoy <vega.james@gmail.com>
Using system('tty') will always report "not a tty", since the spawned shell
has stdin redirected. In order to get an accurate value for $GPG_TTY when
it's not already set, read the output of the tty command using :!.
This requires a bit more setup/teardown to ensure the buffer and user's undo
state aren't affected, but it's the only way to accurately determine the
user's tty.
Closes: #1
Signed-off-by: James McCoy <vega.james@gmail.com>
It's possible that gpg will work fine without $GPG_TTY being set (e.g., when
using a GUI pinentry program). Therefore, the message should be classified as
a warning, not an error.
Also, use a single :echom to ensure the user sees the entire message, not just
"gpg-agent might not work."
First part of GH #1
Signed-off-by: James McCoy <vega.james@gmail.com>
Whenever GPGFinishRecipientsBuffer is called, the buffer is processed to
convert names to IDs. However, this was ignoring any existing ID information
in the buffer. This meant that if a person had multiple keys, the user would
be prompted to disambiguate the keys after every :GPGEditRecipients session.
Parsing the ID out of the recipients buffer avoids the unnecessary prompting.
Signed-off-by: James McCoy <vega.james@gmail.com>
After opening a file, an immediate "u"/":undo" would remove the entire
contents of the buffer. Even worse, this would not set 'modified', so there
would be no indication that wasn't the actual initial state of the buffer.
Discarding undo history for a buffer requires a few steps, including making a
change. Luckily, a change is already being made (deleting the extra line left
after ":r !" the decrypted file), so discarding undo history can piggy-back on
top of that.
Signed-off-by: James McCoy <vega.james@gmail.com>
This is another step to prevent writing out sensitive information to disk.
Typically, when running an external command, Vim writes the command input (the
buffer in this case) to a file in a private temp directory. When
'noshelltemp' is set and the system supports it, Vim uses pipes to the child
process to handle this instead.
Signed-off-by: James Vega <vega.james@gmail.com>
The two argument form of shellescape() is now being used, and that was
introduced in the pre-releases of 7.2.
Signed-off-by: James Vega <vega.james@gmail.com>
With this change, we're able to properly handle errors from shell commands.
This means no more overwriting the original file when an incorrect password is
entered or some other similar scenario.
Also, move the handling of entering recipients to gpg itself instead of
mimicking that in Vim itself.
Signed-off-by: James Vega <vega.james@gmail.com>
Whenever GPGFinishRecipientsBuffer is called, the buffer is processed to
convert names to IDs. However, this was ignoring any existing ID information
in the buffer. This meant that if a person had multiple keys, the user would
be prompted to disambiguate the keys after every :GPGEditRecipients session.
Parsing the ID out of the recipients buffer avoids the unnecessary prompting.
Signed-off-by: James McCoy <vega.james@gmail.com>
After opening a file, an immediate "u"/":undo" would remove the entire
contents of the buffer. Even worse, this would not set 'modified', so there
would be no indication that wasn't the actual initial state of the buffer.
Discarding undo history for a buffer requires a few steps, including making a
change. Luckily, a change is already being made (deleting the extra line left
after ":r !" the decrypted file), so discarding undo history can piggy-back on
top of that.
Signed-off-by: James McCoy <vega.james@gmail.com>
