Steve PurcellFirst example we at MELPA have seen of an #emacs package getting hacked (upstream of us, in GitHub): https://github.com/kubernetes-el/kubernetes-el/issues/383
If installed, loading this compromised #emacs library would trigger the embedded shell command. Not very subtle, but this should be a reminder to the dev community that plugins for even niche dev tools can be an attack vector.
J3RN 
@sanityinc It's events like this that make me want to just write all my own Emacs packages
@j3rn it's not impossible: https://www.rahuljuliato.com/posts/emacs-solo-two-years
@sanityinc I already use almost exclusively my own Elixir tooling. I think the only non-built-in package that I use and would struggle to replicate is Magit. So maybe that's just a "pin to commit" situation 🙂
technomancy@j3rn @sanityinc I've been running on magit from 2011 for ... well, since 2011
and using subtrees to lock in all my packages in my dotfiles repo for nearly as long; works great and I highly recommend it
@technomancy @sanityinc Makes sense, but I'm debating if it's more efficient to manually verify updates or just implement the packages myself. Probably differs on a per-package basis, if I had to guess.
@j3rn @sanityinc I didn't do this from the start, but a couple years ago I started a policy of reading every line of elisp in a package before adding it
of course it has the effect of making sure I don't add a lot of elisp to my setup, but I think that's a good thing
@j3rn @sanityinc also if you're looking to reduce your exposure but can't manually review some of the more popular packages, things like magit and exwm can be installed from apt, where they A) get updates at a less-risky pace and B) have a packaging team that is responsible for reviewing each update for you