If 'autowrite' is set, an encrypted buffer is modified, and ":q!"/"ZQ"
is executed, GPGCleanup's "only!" would cause the buffer to be
abandoned. Due to 'autowrite' and the VimLeave autocmd not using
"nested", abandoning the buffer causes Vim to write the buffer, which is
currently unencrypted, overwriting the encrypted file with plain text.
Since the user can more reliably clear their own console/terminal scroll
back than we can, simply remove this functionality. It's safer than
trying to unwind the twisty passages of Vim's autocmds, especially those
of the *WriteCmd variety.
Closesjamessan/vim-gnupg#77
Signed-off-by: James McCoy <jamessan@jamessan.com>
In the refactor to use the *Cmd events, an unencrypted file was simply
:read into the buffer. This incorrectly caused an extra blank line to
be added to the top of the buffer.
The handling of encrypted files properly handles this, as well as
triggering BufRead(Pre,Post) events.
Instead of returning early for unencrypted files, go through the same
steps as for encrypted files (minus the encryption specific steps), thus
preserving the content of the original file.
In dda14abb3c, GPGCleanup added 'set
buffhidden=hide' to try avoiding error messages when modified buffers
are being abandoned. However, that only works if the buffer is the last
visible buffer.
If there are windows displaying multiple buffers, then errors can still
be emitted. Using "only!" ensures all the other windows can be closed.
Signed-off-by: James McCoy <jamessan@jamessan.com>
When Vim has decided it can exit, GPGCleanup forces a blank buffer to
take over the screen so contents aren't visible in scrollback. However,
if the buffer is modified and 'hidden' isn't set then the command will
fail.
Force the buffer to be hidden, so this is avoided.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Since the user can control which file patterns are handled by the plugin
(via g:GPGFilePattern), the regular expression checking the buffer name
for GPGEdit{Recipients,Options} may not match. A simpler and more
definitive check is to see whether b:GPGCorrespondingTo is set to
determine if the buffer is an existing recipients/options buffer.
Closesjamessan/vim-gnupg#72
Signed-off-by: James McCoy <jamessan@jamessan.com>
Changing &encoding when &fileencoding != &encoding causes two problems.
First, it's completely unsafe to change &encoding after vim is running,
since there may be characters that can't be translated from one encoding
to another, which can make vim crash.
Second, this actually loses information about the buffer's encoding.
When the encrypted file is opened later, it won't be in the same
encoding as before it was saved. Changing user's data on them is
unacceptable.
Signed-off-by: James McCoy <jamessan@jamessan.com>
If the user is using "vim -R"/":view", then the opened buffer should
have 'readonly' set, even if permissions would otherwise allow editing.
Closesjamessan/vim-gnupg#67
Signed-off-by: James McCoy <jamessan@jamessan.com>
When the user hasn't explicity let g:GPGPreferArmor, the value is
supposed to be determined by the filename. Instead of letting
g:GPGPreferArmor, lazily determine what should be done when actually
doing the encryption.
Signed-off-by: James McCoy <jamessan@jamessan.com>
Renaming the temporary, encrypted file to the intended filename (per the
buffer) may fail (e.g., typoed directory name). In this case, remove
the temporary file and then give the typical error message for this
situation.
In order to be safe, the message is manually being generated instead of
trying to be clever and do something like “noautocmd write” expecting it
to hit the same error that rename() did.
Closesjamessan/vim-gnupg#56
Signed-off-by: James McCoy <vega.james@gmail.com>
When --throw-keyids, --hidden-recipient, or --hidden-encrypt-to were
used for an encrypted file, the encryption metadata uses all zeroes as
the key ID. Ignore these key IDs to avoid generating extraneous
messages during decryption or adding invalid IDs to the recipients list.
Closesjamessan/vim-gnupg#50
Signed-off-by: James McCoy <vega.james@gmail.com>
If a user has 'shellslash' set in Windows, then filename related
functionality uses forward slashes instead of backslashes. This breaks
running of external commands because some external commands in Windows
treat any forward slash as a command line switch.
This change adds s:shellescape(), which wraps Vim's shellescape(), but
ensures 'noshellslash' is set first in Windows command prompt (not
Cygwin or msys) environments. Having 'noshellslash' set when
shellescape() is called causes the string to be quoted, regardless of
whether there is whitespace or typical special characters, thus avoiding
the interpretation of the string as being command line switches.
Closesjamessan/vim-gnupg#41
Signed-off-by: James McCoy <vega.james@gmail.com>
In non-Windows environments, the gpg command is prepended with “LANG=C
LC_ALL=C” to ensure gpg's output is consistent to allow for parsing the
information. However, that doesn't work in Windows and won't
necessarily work if we ever remove the code forcing use of /bin/sh.
Since Vim already knows how to influence the environment, use its
“:language message …” command to set/restore the locale before/after
running the gpg command.
Closesjamessan/vim-gnupg#45
Signed-off-by: James McCoy <vega.james@gmail.com>
If the “log-file” option is set in ~/.gnupg/gpg.conf, then using “--batch”
means that the CLI's “--logger-fd” is ignored. Since this command
shouldn't need any of “--batch”'s functionality and “log-file” hides all
the output we're expecting, dropping “--batch” is the sane thing to do.
Closes#40
Signed-off-by: James McCoy <vega.james@gmail.com>
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
# Changes to be committed:
# modified: plugin/gnupg.vim
#
# Untracked files:
# foo.asc
# foo.gpg
# foo.sig
#
# ------------------------ >8 ------------------------
# Do not touch the line above.
# Everything below will be removed.
diff --git c/plugin/gnupg.vim i/plugin/gnupg.vim
index 80f2061..b0bcd5c 100644
--- c/plugin/gnupg.vim
+++ i/plugin/gnupg.vim
@@ -1,5 +1,5 @@
" Name: gnupg.vim
-" Last Change: 2015 Jul 16
+" Last Change: 2015 Jul 26
" Maintainer: James McCoy <vega.james@gmail.com>
" Original Author: Markus Braun <markus.braun@krawel.de>
" Summary: Vim plugin for transparent editing of gpg encrypted files.
@@ -448,7 +448,7 @@ function s:GPGDecrypt(bufread)
" find the recipients of the file
let cmd = { 'level': 3 }
- let cmd.args = '--verbose --decrypt --list-only --dry-run --batch --no-use-agent --logger-fd 1 ' . shellescape(filename)
+ let cmd.args = '--verbose --decrypt --list-only --dry-run --no-use-agent --logger-fd 1 ' . shellescape(filename)
let output = s:GPGSystem(cmd)
" Suppress the "N more lines" message when editing a file, not when reading
Starting with release 2.1, gnupg will automatically run gpg-agent rather
than requiring it to be run as a daemon. The “--no-use-agent” switch
was also marked deprecated, since it no longer does anything.
This commit moves the --(no-)use-agent handling until after it is known
what version of gpg is being used.
Closes#37
Signed-off-by: James McCoy <vega.james@gmail.com>
Resetting &term can affect various settings which are terminal
dependent (e.g., escape sequences described at “:help :set-termcap”).
Emitting TermChanged allows people to re-set these options so they don't
lose functionality (c.f. jamessan/vim-gnupg#28).
Signed-off-by: James McCoy <vega.james@gmail.com>
:lockmarks doesn't appear to preserve these marks. They would need
to be adjusted anyway due to the line numbers changing, so just set the
marks to the start/end of the buffer.
Signed-off-by: James McCoy <vega.james@gmail.com>
After Vim runs certain commands (e.g., pinentry-curses), the terminal is
not returned to its previous state. This causes some escape sequences,
like arrow keys, to stop being recognized properly by Vim.
Re-setting &term to itself causes Vim to go through its normal terminal
initialization steps which gets things back in working order.
Closesjamessan/vim-gnupg#17
Signed-off-by: James McCoy <vega.james@gmail.com>
Allow to set initial contents for recipients menu with
g:GPGRecipientsMenu. Example usage:
let g:GPGRecipientsMenu=""
\."GPG: Example User <example@example.com>\<NL>"
\."GPG: Other User <otherexample@example.com>\<NL>"
glob() reports false positives if the filename has metacharacters in it
(e.g., "[...]"), which causes Vim to incorrectly open a new, blank
buffer instead of the specified file.
Closesjamessan/vim-gnupg#12
Signed-off-by: James McCoy <vega.james@gmail.com>
This was lost in the refactor of external command handling, commit
7d102c843, and was causing an unnecessary "Press ENTER …" prompt to be
emitted whenever the buffer was written out.
Signed-off-by: James McCoy <vega.james@gmail.com>
If there are specific actions that should take place when editing a
GnuPG-managed buffer, an autocmd for the User event and GnuPG pattern
can be defined. For example, the following will set 'textwidth' to 72
for all GnuPG-encrypted buffers:
autocmd User GnuPG setl textwidth=72
This will be triggered before any BufRead or BufNewFile autocmds, and
therefore will not take precedence over settings specific to any
filetype that may get set.
Closesjamessan/vim-gnupg#10
Signed-off-by: James McCoy <vega.james@gmail.com>
The previous behaviour of this plugin was to open the recipient pane
immediately after opening a new file with the correct extension. The
documentation states that this should still occur, so this commit
implements the behaviour in a slightly different manner than the old
plugin.
If a user :w's when in the options or recipient panes the global
bufwrite handlers will be called, triggering an attempt to encrypt the
file. The user will be dropped into the command line recipient adding
process, and the recipients listed in the buffer will be ignored.
This commit checks to see if a buffer is a child of another by looking
for the buffer local var containing the parent buffer name, and only
runs the encryption if it is not present.
Need to use copy() when setting b:GPGRecipients in GPGDecrypt(), otherwise the local variable will act as a reference to the global one. The result will be that the global default recipient list will become a super-set of recipients as multiple gpg files are opened.
