You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By default, vim-gnupg uses tempfiles, not pipes (GPGUsePipes = 0here). That means that during write operations, plaintext gets (briefly) written to a temporary file usually under /tmp. This can be accessed by other processes, and even may be written to disk, depending on how /tmp is set up on a given system. If it gets written to disk, even if deleted shortly thereafter it may be retrieved from the disk afterwards using simple forensic tools. Given that vim-gnupg is used "for security purposes", I think it would be great to inform users about this.
Steps to reproduce:
Window 1: open an encrypted file using vim-gnupg
Window 2: enter the corresponding temporary directory in /tmp (with neovim 0.5, it's named something like nvimp6pF1c) and run while :; do find . -type f -exec cat {} \;; done
Window 1: save the encrypted file: :w
Window 2: observe (parts of) the plaintext being printed to the terminal
I suggest to include a warning about the consequences of setting GPGUsePipes = 0 in doc/gnupg.txt.
I also suggest to include a similar warning in the README.md of this repository, as long as GPGUsePipes defaults to 0, like it currently does.
Finally, I think it is desirable to set GPGUsePipes = 1 if the issue with terminal-based pinentries not displaying correctly is solved.
The text was updated successfully, but these errors were encountered:
I seem to recall that if tempfiles are avoided, there is no way for vim to properly detect the the encoding of decrypted text during a read. Everything is fine if the underlying cleartext is encoded the same as &enc/&tenc, but e.g. I found that if I encrypted a latin-1 encoded text, and had &nostmp set, my vim buffer would have some gibberish in it.
I believe even :help stmp says that one of the benefits of using temp files over pipes is that it allows encoding to be detected.
If that's right (maybe it isn't!) then one of the suggestions in this PR would make it so that this plugin is set up by default to mangle people's documents---silently, if the mangled pieces are not visible on screen during an editing session.
I seem to recall that if tempfiles are avoided, there is no way for vim to properly detect the the encoding of decrypted text during a read.
I believe this should work fine with the current state of the plugin. However, I'm working on refactoring the plugin to address some outstanding issues, and it will require upstream changes to handle that.
The bigger issue with GPGUsePipes = 1, as I recall, is that it causes more interference with terminal-based pinentry. Those are already unreliable with full-screen apps like Vim, so if you're a GUI one, then GPGUsePipes = 1 should be fine.
By default, vim-gnupg uses tempfiles, not pipes (
GPGUsePipes = 0
here). That means that during write operations, plaintext gets (briefly) written to a temporary file usually under/tmp
. This can be accessed by other processes, and even may be written to disk, depending on how/tmp
is set up on a given system. If it gets written to disk, even if deleted shortly thereafter it may be retrieved from the disk afterwards using simple forensic tools. Given that vim-gnupg is used "for security purposes", I think it would be great to inform users about this.Steps to reproduce:
/tmp
(with neovim 0.5, it's named something likenvimp6pF1c
) and runwhile :; do find . -type f -exec cat {} \;; done
:w
I suggest to include a warning about the consequences of setting
GPGUsePipes = 0
indoc/gnupg.txt
.I also suggest to include a similar warning in the
README.md
of this repository, as long asGPGUsePipes
defaults to0
, like it currently does.Finally, I think it is desirable to set
GPGUsePipes = 1
if the issue with terminal-based pinentries not displaying correctly is solved.The text was updated successfully, but these errors were encountered: