Live data from Hacker News

Vim blowfish encryption

dgl.cx

1–10 of 18 posts

Re: Vim blowfish encryption

#2
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.

Re: Vim blowfish encryption

#3
post #2

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.

Re: Vim blowfish encryption

#5
post #3
post #2

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 i…

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.

Re: Vim blowfish encryption

#6
post #2

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.

vim ships with xxd since decades

Re: Vim blowfish encryption

#8
post #3

Earlier quoted context omitted.

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 i…

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.

Re: Vim blowfish encryption

#9

I am beginning to think Vim has too many features. And it must be hell managing that codebase.

That is why neovim maintainers decided to remove encryption from the codebase. check https://github.com/neovim/neovim/issues/694 and https://github.com/neovim/neovim/pull/699

No, this is one thing I love Vim for and use it. It is fixed going forward. It is the only x-platform one that isn't messy at some point.

Re: Vim blowfish encryption

#10
post #8

Earlier quoted context omitted.

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…

Exactly why I love that it is baked into Vim.
Post reply on HN