1. 47
  1. 17

    As a security researcher and cryptography hobbyist, I appreciate that Neovim took out Vim’s unauthenticated and broken Blowfish encryption support. Blowfish is a 64-bit block cipher which is vulnerable to Sweet32. I brought this up to the Vim project, and unfortunately heated emotions took over, and the issue was closed. Further, Vim’s password hashing function for key derivation is weak. This issue remains open.

    Regardless, Neovim does not support :X to encrypt data. As such, if you want built-in encrypted text, you’ll either need to use the gnupg.vim plugin, or write something that hooks into an external tool, like OpenSSL.

    Edit: spelling

    1. 3

      Huh, that’s interesting. I didn’t know that was such a contentious ‘issue’ with the vim folks..

      1. 4

        That was a wild read. Reminds me of the gendered pronouns issue

        1. 7

          It’s not a contentious issue with Vim users per se. It’s a contentious issue with cryptographers and Bram Moolenaar. But yeah, it’s a bit silly TBH.

          1. 11

            I use Vim’s blowfish feature; just for some files that aren’t super-sensitive but also don’t want showing up in a grep or be easily readable for anyone (they would have to get access to my computer first, which is already a significant barrier).

            I dislike using gpg with a passion, and integrating external tools in Vim and doing it well is actually harder than it might seem (though not impossible). Clearly it can all be improved, e.g. by using libsodium or whatnot; actually, it seems there is even a TODO entry for that.

            I’ve seen several discussions about this, and the problem is always the same: people (often actually the same people) will start being caustic, start ranting about blowfish, “brokenness”, “laziness”, etc. and at this point the entire conversation/issue gets sidetracked and you’re no longer talking about how to improve Vim’s crypt feature, the maintainers get exasperated (rightfully so, IMO), and nothing gets done because, basically, “fuck this guy”. This is what happened to your issue, which was fine, but got hijacked by this other guy who used it to rant.

            From a UX point of view, it’s by far the most convenient way to encrypt a text file, and this has a lot of security value too. A number of crypto people tend to hyper-focus on algorithms, and those are not unimportant of course, but it’s just one part of the entire cryptosystem.

            It’s not just Bram who opposes outright removing this feature, other Vim maintainers such as Christian do too.

            tl;dr: someone just needs to make a patch to add libsodium integration instead of ranting about blowfish and it would all be better.

            1. 5

              I just use Mozilla’s sops. It supports a wide variety of key stores and uses $EDITOR.

              1. 3

                I dislike using gpg with a passion

                And for good reason. PGP is littered with problems

                by using libsodium or whatnot; actually, it seems there is even a TODO entry for that.

                This is good news. I wasn’t aware this was on the TODO. Hopefully this comes sooner than later.

                1. 2

                  FYI: https://github.com/vim/vim/pull/8394

                  Looks like help/advice/feedback is requested, if you’ve got the time and inclination :-)

                  1. 1

                    This is great! Thanks for doing this!

                    I comment on your PR about not replacing the sha256_key() KDF with crypt_pwhash_*. I don’t know if that’s something you plan on addressing or not, but because you reference issue #639, I thought I would mention it.

                    1. 2

                      It’s not my PR; I just happened to notice it and thought you might be interested 😅

                      I did actually work on this a little bit a few weeks ago, but I’m a crappy C programmer and it was more complex than I thought, so I quickly gave up.

                      1. 1

                        Ah, fair. Thanks for bringing it to my attention regardless. I’ll be following it.

      2. 4

        sorry if the question is naïve,

        but does Neovim or any other lsp-enabled modern vi-inspired editor provide Emacs key binding ?

        reason I am asking is because I am not a ‘elisp’ user and do not extend or configure emacs that much – but emacs key bindings is the only thing I know.

        For my ‘quick shell tasks’ I use joe (that has the jmacs command that enables emacs keybinding) – so I was thinking that may vi-inspired editors can do the same.

        1. 8

          Learning vi keybindings pays off in multiples. There are so many applications (especially in terminal) that default to vi binds that you will often be pleasantly surprised how things “just work” if you try them.

          1. 2

            i’m not convinced that this is a good argument as to the benefit of vi binds. there are advantages to vi binds. that other things use them by default doesn’t seem up there at all.

            you can get *some* emacs-style bindings in vim, i know because i’ve tried. but emacs or an emacs clone works better for that, and vim works better for vimmish modal editing.

            1. 8

              Having a ‘standard’ keybinding across multiple applications out of the box is quite useful.

              1. 2

                sure. but saying it pays off in multiples to learn a confusing keybinding system purely for that reason seems like a cyclic argument.

                the original commenter wants to make neovim work like emacs. i agree that they are better off learning the vi binds if they want to use a vi-family editor. i think that there are much better justifications for doing that then “other tui applications are likely to support them”.

                1. 1

                  I live in the terminal and I’m struggling to think of many examples of other apps that use vi bindings. Meanwhile I also use neovim nearly all the time and I, like most regular vim users, change the (historic but awkward) default bindings. And I use Emacs-style shortcuts in the line editor.

                  1. 3

                    like most regular vim users

                    Wait really? Aye you saying most vim users don’t use hjkl to navigate? Or are you referring to something else?

                    1. 5

                      To be honest, I suspect there’s a surprising amount of Vim users that use arrow keys. I’m one, and it’s not like I’m hunt-and-peck, only use arrow keys. I use them in addition to motions, because I could never develop the muscle memory for hjkl. It just doesn’t feel right to me, and the last thing I want to do is get used to it and start spraying hjkl into every non-vi editor I see.

                      1. 3

                        I did develop the muscle memory at one point, and regretted it. I think hjkl is the most obsolete part of vim, they’re some good keys being taken up with commands that don’t need to be used that often, if you’re using vim effectively.

                        1. 2

                          As someone using a 60% keyboard without cursor keys I have found rebinding the default cursor mappings to hjkl to work rather well since these keys are much more convenient to reach than where cursor keys usually are. So maybe one doesn’t need hjkl in vim but the mapping is surprisingly useful outside of it.

                          (I also accidentally discovered these vim bindings in Evince by forgetting to use modifier keys and just spamming j/k into the PDF reader)

                          1. 1

                            You should be able to rebind them to your preference, though I don’t know if external scripts would break.

                            I always disliked moving my hand to the cursors, and now that I’ve been on a Kinesis Advantage since forever - whose cursors are crazy awkward - I would hate to have to use them.

                            Also someone said he /she uses hjkl on Dvorak!

                            Definitely YMMV based on the keyboard and its layout as well. FWIW I do kinda suck at using anything without a Vi mode anyway, beyond just the navigation.

                            1. 2

                              I do you use hjkl on Dvorak. Not as much in Neovim, because I don’t need these motions, but in firefox (Vimium C), in evince, in tmux (remapped). It works just fine. Of course they are not next to each other (except awkwardly placed jk), but I don’t think about it and it works fine anyway.

                        2. 1

                          I don’t know whether most regular vim users use hjkl in particular (I don’t. It could be interesting to survey vim users on questions like this!), but I was talking more generally. I think it’s very common to either remap Esc or bind something else to leave Insert mode, since reaching for Esc is widely thought to be awkward. I’ve also seen many example vimrcs that map ; (or something else) to : to avoid having to shift for it. I think it’s common to remap the leader too.

                          1. 2

                            Yeah I remap Esc to caps lock.

                            But I do use hjkl to navigate (in lieu of arrow keys anyway, when I’m not using other types of motions). That’s the part that I was surprised by. Not in a bad way or anything. Just one of those things where I thought basically every Vim user used hjkl. But I guess it’s just anecdotal.

                            1. 1

                              I also use hjkl to navigate, and I would remap Esc if I didn’t remap my keyboard to making pressing Esc easier.

                        3. 2

                          quite a few programs have vi binds - cmus, ranger, either mutt or newsboat, but i don’t think both. i’m not a vim user anymore so i couldn’t comment on how modern regular vim users work, but i do see little benefit to not changing any of the keybindings.

                          theres often the “what if im on a server without my dots?” argument, i guess.

                2. 6

                  Kinda sorta not really. Neovim (and Vim) are built from the ground up in the vi-style modal paradigm, and they aren’t a fully configurable environment like Emacs where you could swap out the whole concept of modes for something else (aka, Emacs-style modes/bindings). The closest you can get is rebinding keymaps in insert mode to be closer to Emacs, like Tim Pope’s readline plugin does.

                  1. 1

                    Thank you. I will look into this.

                    I prefer to code without touching a mouse. As my shoulder and neck hurt (I switch hands for the mouse, periodically as I am used to operate it ambidextrously, but it still hurts after a month – when I do 7-8K lines per month, or lots of debugging).

                    Which is why I prefer Emacs. Big problems with Emacs however for me are as follows:

                    a) JS type validation using FB Flow across all of my mono repo subprojects - does not work

                    b) Gradle based projects (Android apps and my Java backends) – do not work

                    c) Java refactoring capabilities are not in the same league to Android Studio / IntelliJ

                    So I thought VI-based ecosystem might be more developed in those areas. At the moment I just use Emacs key bindings in VS Code (for JS/Flow) and intelliJ (Java/Android) – but i seem to be grabbing mouse there too often.

                    When I work my Ansible side of things (Yaml configs) – I use emacs almost exclusively and in a Terminal window (even though I can run a GUI session, I prefer just a terminal or a login console).

                    1. 1

                      What a great name for that plugin! https://en.wikipedia.org/wiki/Repetitive_strain_injury

                      1. 1

                        I love vim-rsi! @lollipopman also made a similar thing for bash, in case you share terminals with people (pairing, debugging, etc). and can’t stand emacs mode and they can’t stand vim mode: https://github.com/lollipopman/bash-rsi

                      2. 2

                        Not that I know of, but Emacs has LSP plug-ins so if LSP is what you’re after and you’re comfortable using Emacs I see no reason to switch.

                      3. 2

                        The big concern I have with neovim 0.5 is that something akin to spacemacs’ master-develop split will occur. 0.5 has been looming on the horizon for a long time now, and I hope that they can reconcile the fracturing landscape between 0.4 and 0.5 plugins by releasing soon.

                        1. 4

                          AFAICT all (or the overwhelming majority of the) plugins for 0.4 will work with 0.5.

                        2. 1

                          Can someone who has migrated from vim to nvim recommend a guide for doing so, or if it’s really just as simple as changing to init.vim? I’m also wondering if folks keep compatibility layers in dotfiles repos, or anything like that.

                          1. 5

                            We added a skeleton init.vim so you can just use your normal vimrc when we started using nvim: https://github.com/braintreeps/vim_dotfiles/blob/416912bb64a034241a40906693c0298dc5d8ea49/config/nvim/init.vim

                            Then you can just start vim or nvim depending on if you want to shave yaks or to be classically productive.

                            1. 2

                              If I recall correctly (I used nvim a while ago, I think the latest was 0.2), you can start by just changing your .vimrc to init.vim, and then go from there.