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.
Great tips from @tarsius on how to reduce the risk of your GitHub actions being hacked like this: https://www.reddit.com/r/emacs/comments/1rowm5i/comment/o9hxc10/
Ashish Panigrahi@sanityinc Strange that the PR was merged without maintainer approval.
@paniash I commented on the issue — I think the attacker stole a github token via a privileged Actions run that was made without needing the maintainer's approval.
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
Теодор Златанов / Ted Zlatanov@sanityinc good thread on
this when it was just theoretical https://www.reddit.com/r/emacs/comments/1i1u0rj/how_does_the_emacs_community_protects_itself/?rdt=45984
this when it was just theoretical https://www.reddit.com/r/emacs/comments/1i1u0rj/how_does_the_emacs_community_protects_itself/?rdt=45984
@tzz Yeah, many such discussions in the past. IIRC Emacs 31 will have built-in support for diffing package updates before full installation. In this case, the modified file would not have got past the MELPA build step, so we won't have distributed it, but there's no particular barrier to crafting a malicious package that *would* get built.
@tzz "Maintainer gets compromised" is a very difficult thing to mitigate centrally.
Elias Mårtenson@sanityinc @tzz And Emacs is by necessity a tool that have wide-ranging access to the system where it's run.
I have been worried about this very thing for a while, in fact every time I install a MELPA package.
Alex Schroeder@loke @sanityinc @tzz Same. And what if I'm root? Do I even install packages? I guess I shouldn't. 😬
Chip Butty
Holger@alex I mostly use jed as root, that's usually good enough for the minor editing needs I have as root. Everything that requires more comfort and capabilities will be done with my normal account and then run as root.
@loke @sanityinc @tzz
@loke @sanityinc @tzz
@schaueho @alex @sanityinc @tzz I'm not worried about anyone getting access to root. All the sensitive data and actions are available to my regular user, ao that's what I want to protect.
The only approach that works reasonably well today is that of Qubes OS, but it still suffers from the limitation of not exposing any GPU functionality, which is a blocker for many usecases.
@sanityinc Then the risk of this is not increased (at least not too much) when considering root.
However, given that there are still files that only root can access and things that only root can change on a system, I actually think that usually the risk would be higher for root. But it's not a big point, agreed.
@loke @alex @tzz
@schaueho @sanityinc @loke @tzz I am worried about rm / in all code. Every time I edit files in /etc I use sudo or root. If Debian packages something I can be reasonably sure that the code is not super malicious. Maybe tracking and telemetry, etc. But anytime I install a bleeding edge thing from npm, PyPI, CPAN, MELPA or whatever to use as root, I start sweating. I try to minimise it and sometimes I forget. asncounter was available from trixie-backports, lucky! I can get rid of this pipx install. Emacs apache-mode or nftables-mode is not packaged by Debian and I only need those for files owned by root. Tricky!
deech@deech I'm coming to appreciate that it (gestures vaguely all around) is so openly a joke
Shane Celis@sanityinc @deech Dev tools have been so lax on security and so trusting, I figured they were only left alone because they’re a small target. Scary to see Emacs malware in the wild though.
@shanecelis @deech yeah, if this is an easy-to-find toy attack, it doesn't seem impossible that a genuine one has already succeeded
@sanityinc @deech One solo security-conscious developer examines the last of the builtin Emacs packages: woman.el. “Ok, it’s safe to use. Ten months well spent.”
synlogic4242
Ross A. Baker@deech @sanityinc Maybe new accounts that suddenly open PRs en masse, that reference a known malware repo, to repositories related only by having a vulnerable configuration, and leave behind a picture of one Mr. Richard Long, could be detected as a malicious signal by the company that enjoys a near monopoly on open source.
Hey, look, another Copilot button!