https://glyph.twistedmatrix.com/2015/11/editor-malware.html is a post describing the problem and some solutions. I haven't checked to see how many of the steps are still necessary on Emacs 26, but I bet it's still non-zero.
https://glyph.twistedmatrix.com/2015/11/editor-malware.html is a post describing the problem and some solutions. I haven't checked to see how many of the steps are still necessary on Emacs 26, but I bet it's still non-zero.
Wouldn't it make more sense to sign individual packages so that it doesn't matter if an attacker can mess with them "in flight"? That's generally how package managers work in my experience. It also means that you can let third parties create mirrors without trusting them fully. TLS doesn't really seem like the right solution for something like that.
You will also need to sign and timestamp all repository metadata. Otherwise when you learn of bug X and fix it with patch P to produce new package package-V+1 I also learn of bug X, but I ensure my victims don't get told about new package-V+1, they will be told package-V is the latest version and they're now safely up-to-date - but I can exploit them.
If you use TLS I can't meddle with the packages, or the metadata, or anything.
You absolutely can secure everything in your package management system, but it will be a bit trickier than just signing individual packages. Whereas using TLS is enough.
Back in 1995 when anonymous FTP distribution was commonplace, signing packages made a whole lot more sense than trying to get all your mirrors to update to HTTPS. In 2018 this is not so true.
See if this works for you on Emacs 25 and 26: https://news.ycombinator.com/item?id=17573969