Peeve: software that’s configured by setting this variable in this file, unless it was compiled with some option, then it’s that variable in that file, unless you’re running gnome, then it’s over there unless you’re running on a mac, then it’s over here. For bonus points, make it booleanesque, but have setting=1 and setting=true do slightly different things.
Emacs' package system is okay, but the fact that you get TLS errors out of the box is inexcusable. I had to replace https with http to get anything to work. That’s not a confidence booster.
Still, the convenience of not having to manually install and manage the load-path outweighs the security concerns for my personal use. Barely, though.
I use pathogen.vim to install packages. If I only git clone via HTTPS (and I do—it’s the Github default), it should be the same as using vim-plug as the post suggests, right?
In fact, if you are using sources from anywhere without auditing, it doesn’t really matter.
You are just avoiding that the code is replaced in its way to you, but if the exploit is already there in the repo, that’s it. Just like piping wget https…. | bash.
At last is a question of trust. Who says that the emacs or vim mantainer hasn’t put any backdoor there? We can only trust the many-eyeballs audit done by the “community”.
I’d also estimate this to be a far more likely malware vector than my ISP backdooring emacs packages by rewriting them on the wire while they’re en route to me over HTTP.
I’m curious, has this ever been observed in the wild? Has anyone ever been infected through a vim or emacs package?
The author complains about not users not auditing installed plugins, but then recommends a new solution by saying:
“I haven’t audited it conclusively but its relatively small codebase includes lots of https:// and no http:// or git:// that I could see.”
That seems like somewhat of an audit to me ;-)