@joeyh That seems to be about the shape of it: check the signatures on extensions regularly to allow revocation, and as it turns out if something higher in that chain is invalid, the signature is invalid. (This isn't necessarily *bad*, as you might have good reason to revoke an intermediate cert as well, but obviously in this case it didn't go as one might like.)
My guess is so that a malicious virus/trojan-installed extension would not load successfully. e.g. a virus could install an extension in Firefox to keep reinstalling the virus, or to let it rum traffic through FF's process to evade antivirus, etcetera. If certs were only checked at install-time then a manual install could bypass cert checks. Being checked at runtime guarantees that what runs is what's trusted.
@joeyh I think it was intermediate certificate, so everytime the extension runs, or maybe everytime firefox starts, it checks the signatures of all extensions against their certificate. But since the respective certificates are signed by this intermediate certificate, the signature is only valid when all certs in the chain are valid. That's my guess. Why didn't they have any expiration warning or why this exact problem wasn't addressed when it happened 3 years ago, that's mystery
@joeyh interesting denial of service concept
@joeyh I was wondering what that message was about... it didn't actually stop any of my extensions though... weird.
@joeyh In theory, they COULD say that the system is designed to remove and inactivate anything with a bad key (including expired keys) to prevent the installation and activation of bad extensions. It's a stretch, but a possibility.
@joeyh I believe Java breaks that way too.
What it's trying to guard against is malicious downloads that do ad-hijacking and so on. A guy unwittingly clicks a bad link, which installs a malicious plugin.
Mozilla is not in control during that installation, so only option is to kill it as you start mozilla and load plugins.
@youzicha @joeyh It's much harder to make a case for *expiry* of the signatures after they have been accepted; and it doesn't in fact check for expiry on every startup, only at 24-hour intervals - so the damage would already be done by a malicious plugin installed offline while the browser wasn't running.
Installation as FF wasn't running is what this is trying to fix.
For a malicious plugin, it's not that a sig was first "okay", it's that FF didn't look at that sig at all until its 24-hour tidying up. So that plugin can show bad ads for a day or so, but FF sig validation will kill it.
@youzicha @joeyh If a malicious plugin can ever run at all, you're hosed; they are arbitrarily powerful. So, since you cannot guard against offline malicious installation. The best you can do is - as FireFox already does with certificates of Web sites - remember whether you have accepted a plugin in the past. And then, if you have, don't suddenly break it. Your record of that can be tampered with offline, of course, but you cannot prevent offline tampering anyway.
I think it did work, in that it got rid of most malicious plugins. (Which was a big worry until introduction of this sig validation.)
Obviously it's not foolproof, but this way a malicious program must patch FF binary to avoid validation, it can't piggyback on normal plugin installation.
As I said, FF can't know if sig was okay'd or not, a malicious plugin install could falsify any log of prior validation. That's why it looks at sigs again and again.
@joeyh yes, seems like a Microsoft mindset "we know better than the ignorant user, let's control access to extensions" vs. a Linux mindset would have been "warning: your certificate expired D)elete extension k)eep extension."