to be honest i enabled tsl n all my 10 page blogs a long time ago. but i took a couple days to read about the subject before dicking around aimlessly. so you're spot on.
even when i was on the old unlimited-only-in-name from att which was the same price with a subsided device or not, having my own device still allowed me to:
- avoid crazy fees out of nowhere for canceling (wife had one refurbished $99 note ii. when canceling had to pay almost $200 on top of the values in the contract)
- be able to use own device overseas.
- not have sleazy device protection insurance BS added every month and you having to call in to cancel
while reading this the only thing on my mind is how un-vim that feature is.
i would expect an hex editor mode would make much more sense to be added before they went to such shenanigans feature such as frivolous encryption. which can be trivial to use the Unix way... the way hex editing must be done for great pains btw.
I don't see how you can justify hex editing without justifying encryption. In both cases, you can either do a conversion with a separate tool outside of the editor, edit the converted text, and then covert it back, or have the conversion logic integrated into the editor.
I would argue that, encryption, if implemented properly, is best integrated into the editor because the editor can be sure to store the clear text in mlock'd memory and avoid leaking clear text in other ways (such as into ~/.viminfo). If you have to decrypt with a separate tool, the clear text hits the disk and the editor doesn't know to be careful with it. These are concerns that aren't present with hex editing.
I have no idea if vim is this careful though and sadly I wouldn't count it.
The editor doesn't have to do crypto itself to know it's dealing with sensitive content. A somewhat overblown concern in the age of encrypted swap, anyway.
Cleartext doesn't have to be saved to disk for a separate tool to be used. You can pretty much use GPG from vim as-is just by piping the buffer through it: ":%!gpg -e -a -r yourself" and ":%!gpg -d". The vim GPG plugins can take care of the remaining annoyances.
It's not just swap (I don't think encrypted swap is that common anyways) but also the viminfo and swp files.
The UX for vim's encryption is really good - it's convenient and easy to use. Any replacement would need to be equally easy and well-integrated. If you require users to do manual steps, like type commands or remember to tell vim that it's editing sensitive content, then mistakes will be made that harm security. If the plugin interface can provide a sufficient level of integration, that's great and would be a good alternative to building crypto into vim itself.
Every OS has supported encrypted swap for some time now. It's the default on Macs since Mountain Lion and either the default or a checkbox away on popular Linux distributions. It's a single terminal command in Windows, and encryption of everything is default in Windows 8.1 with a TPM 2.0 module.
They all support general disk/filesystem encryption, too. If you're technically minded enough to be using vim and trying to encrypt files with it, and you're not using an encrypted filesystem to start with, you're pretty nuts.
The core UX for gnupg.vim is open .gpg/.pgp/.asc file, be automatically prompted for passphrase (unless file is new), edit file, save (be prompted for recipients if new). Done.
You're obviously going to have to complain to the vim maintainers about sensitive content. There's been a patch floating around for over a decade to get vim to support mlock. Its blowfish encryption is certainly no safer than gnupg.vim in that regard. gnupg.vim does turn off the viminfo/swapfile/undofile functionality.
> The core UX for gnupg.vim is open .gpg/.pgp/.asc file, be automatically prompted for passphrase (unless file is new), edit file, save (be prompted for recipients if new). Done.
> gnupg.vim does turn off the viminfo/swapfile/undofile functionality.
Thanks. That is excellent UX and knowing that I can agree it's what people should use instead of the built-in encryption.
Just make sure you're using the latest version and set cryptmethod=blowfish2!
Edit: Actually just use gnupg.vim - as nknighthb has explained the UX is just as good as vim's builtin encryption, and then you don't have to worry that this whole thread about vim's builtin encryption was predicated with "...if implemented properly...", which you certainly can't take for granted.
And then reflect on the fact that you're still using a joke of a "KDF". SHA256 1001 times? Really? (And it doesn't even so much as have provision for upping the number of iterations!)
Like TFA says, don't roll your own crypto. GnuPG exists for a reason.
I don't think there's any truth in it. We developed taste buds to guide us to what we should eat and what we should avoid. That evolution has been usurped by food science.
On the other hand, "if it has an ingredient list, it's not food" is much closer to a truism. It's obviously an exaggeration as well; nonetheless, I tred cautiously with ingredient lists.
And now the situation we use our taste buds in is so different from the situation they were trained in that our taste buds are behind the biggest health issue in the world after aging.
you shut up and live it up. or make protests that will be largely ignored, after some police violence, and after posting bail you vote for the 3rd candidate.
