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

Use "--no-auto-check-trustdb" instead of "--trust-model always" #91

Open
jamessan opened this issue Jun 9, 2018 · 5 comments
Open

Use "--no-auto-check-trustdb" instead of "--trust-model always" #91

jamessan opened this issue Jun 9, 2018 · 5 comments
Milestone

Comments

@jamessan
Copy link
Owner

jamessan commented Jun 9, 2018

g:GPGExecutable currently forces --trust-model always in order to avoid the potentially costly trustdb update. This should instead use --no-auto-check-trustdb since that honors the user's trust model but still avoids the db check.

This should happen after any refactoring of how the gpg executable is specified, since g:GPGExecutable currently conflates the executable name along with one of the default arguments.

@blackjackshellac
Copy link

This is a better solution to my suggstion to provide a gpg version toggle. separating executable from options is the right approach but wasn't something I wanted to suggest myself :)

@jamessan
Copy link
Owner Author

jamessan commented Jun 9, 2018

separating executable from options is the right approach but wasn't something I wanted to suggest myself :)

It's something I had been mulling over for awhile, so thanks for prompting me to write it down. :)

@ThomasAH
Copy link
Contributor

ThomasAH commented Jul 3, 2019

--trust-model always (at least originally) isn't about avoiding the costly trustdb update, but to allow using gnupg.vim in a multi-user environment, where a file is encrypted to many people. If one of the recipients edited and saved the file and a key of one of the other recipients wasn't known as valid, this caused an empty .gpg file.

The patch to fix this data-loss was from one of my co-workers.

By now we're setting g:GPGExecutable to a shell script with roughly the following content:

exec gpg --no-options --trust-model always --no-default-keyring \
    --keyring "/some/central/location/keyring.gpg" "$@"

The keyring is centrally maintained by the admins and contains only trusted keys.

So it would be OK for us to remove --trust-model always from gnupg.vim, but for others it might be important to catch the error condition when keys of uncertain validity are used.

@jamessan
Copy link
Owner Author

jamessan commented Jul 3, 2019

--trust-model always (at least originally) isn't about avoiding the costly trustdb update, but to allow using gnupg.vim in a multi-user environment, where a file is encrypted to many people. If one of the recipients edited and saved the file and a key of one of the other recipients wasn't known as valid, this caused an empty .gpg file.

Thanks for the history, @ThomasAH! If you're easily able to reproduce the scenario, could you see if that problem still exists without --trust-model always? There has been a bit of refactoring in how the encryption happens.

@ThomasAH
Copy link
Contributor

ThomasAH commented Jul 4, 2019

With let g:GPGExecutable="gpg", editing the list of recipients, having recipient keys with unknown validity, and answering No (or just pressing Enter) on the prompt Use this key anyway? (y/N), I get the error message Message could not be encrypted! (Press ENTER) and vim refuses to quit
-> this is good

So my suggestion would be to remove the somewhat insecure default, but provide it (and/or --no-auto-check-trustdb) as an example for possible configurations.

Edit: By the way, I tested this with both, v2.6.1 release and current master 6219a5a (which works for me on the machine I just used for the tests, I still have to investigate the problems with master on the other systems).

@jamessan jamessan added this to the 3.0 milestone May 10, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants