Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Docs: Include warning that other processes can read plaintext with default config #119

Open
camoz opened this issue Sep 2, 2021 · 2 comments

Comments

@camoz
Copy link

camoz commented Sep 2, 2021

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:

  • 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.

@chdiza
Copy link

chdiza commented Dec 19, 2022

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.

@jamessan
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants