This is why it is important to cryptographically sign releases. Browsers are a huge problem with this.
All of the software I use is signed at some point in the chain (be it by the actual author or by the package manager, who'd better be verifying signatures if they're available, otherwise at least not blindly updating), _except for my browser extensions_. Most of it is also _reproducible_! I can get around this for some things---I use GNU Guix in addition to Debian, and they package some extensions. I need to start using them.
Of course, the signature should really come from the actual author, not the package maintainer for a particular distro; there's room for error. In the case of a project being hijacked (e.g. Copyfish), hopefully a maintainer would notice. Git commit and tag signing is an easy way to do this if you don't separately sign releases; package maintainers should be building from source.
In the case of Copyfish: if the browser validated signatures from the authors, then this would have been thwarted.
(Maybe there is some code signing protections in place? I'm not an extension developer for either Chromium or Firefox; please let me know if something does exist!)
My understanding is that Chrome extensions are indeed signed and you can't upload updates without signing the new package with the same key, so presumably the attacker had access to the private key after phishing the Google password.
Perhaps it was stored somewhere accessible by that account? Or accidentally packaged with the extension itself? If that were the case the spear phishing attack would make sense: someone scraping the Chrome store for extensions that contain a key file, then phishing their developer account credentials would be more efficient than phishing credentials without knowing beforehand whether you'd be able to get the private key and update the extension.
What's concerning to me is the section entitled "Uploading a previously packaged extension to the Chrome Web Store", which asks the user to place the private key into the package's root and include it in a zip. First: why? Why upload the private key? That leaks it to Google and on top of that stores it in multiple places; the user could forget to delete the zip (and do so securely), for example. And the private key in the root is probably a copy, so that has to be shreded too.
For updating the package, you select the project root as well. If you didn't remove your private key before doing so, I'm assuming you'd be releasing your key?
All of the software I use is signed at some point in the chain (be it by the actual author or by the package manager, who'd better be verifying signatures if they're available, otherwise at least not blindly updating), _except for my browser extensions_. Most of it is also _reproducible_! I can get around this for some things---I use GNU Guix in addition to Debian, and they package some extensions. I need to start using them.
Of course, the signature should really come from the actual author, not the package maintainer for a particular distro; there's room for error. In the case of a project being hijacked (e.g. Copyfish), hopefully a maintainer would notice. Git commit and tag signing is an easy way to do this if you don't separately sign releases; package maintainers should be building from source.
In the case of Copyfish: if the browser validated signatures from the authors, then this would have been thwarted.
(Maybe there is some code signing protections in place? I'm not an extension developer for either Chromium or Firefox; please let me know if something does exist!)