5 ms·

This is not entirely accurate. Nothing was done remotely to disable the add-ons. It happened locally. A certificate that's on your machine as part of the Firefo

This is not entirely accurate. Nothing was done remotely to disable the add-ons. It happened locally. A certificate that's on your machine as part of the Firefox install expired. When that happened, add-ons that were signed via a cert chain that included the expired one started appearing to be invalidly signed. And that's why it requires an update to completely fix. That part is remote, because they need to push a new valid certificate to you to replace the old one. I do think that the UX should ideally be a bit more graceful; one of my add-ons is Multi-account Containers and its being disabled suddenly caused the window I was actively browsing in to just close, among other side effects. But that kind of UX polish for what should be an exceptional case is obviously not going to be super-high priority, unfortunately.

rauhl 7y ago
Clearly, downstream distributors need to create a patch which causes their distributes Firefox builds to only check certificates on add-on installation (and to check revocations too, sure): it should never be possible for a browser to fail into an unsafe configuration.
- wool_gather 7y ago
  What's the difference to the user between "to check revocations too, sure" and what happened?
  - the8472 7y ago
    checking revocations lists != certificate expiry
    - wool_gather 7y ago
      At a the technical level of cert handling, yes. To the user? Not so sure.
    - dwaite 7y ago
      Revocation lists are often tied to certificate expiry, purging entries that are no longer valid due to expiry.
      - the8472 7y ago
        No, revocation lists are orthogonal, often used to invalidate a certificate before it expires.
  - diplocorp 7y ago
    revocation != expiry
- Xylakant 7y ago
  Cert expiration is the only safe revocation. You cannot rely on revocation lists in many settings. Access to them might be maliciously blocked or, if locally kept, tampered with. The list could for example be replaced with an older one, which would circumvent signing the list unless the signature contains an expiration date and then you’re back to “oh, list expired, how do we fail?” You cannot rely on check at extension install. That would assume that all malicious extensions are installed via FF proper. Oracles crapware bundling in the Java installer taught us that’s now how things go. You cannot remember the trust flag when an extension is installed via FF as a crapware installer could just set the trust flag, too. After all, that storage would be accessible, too. You cannot sign or encrypt that trust storage as the key material would have to be kept locally and would be accessible to the crapware installer.
  - rauhl 7y ago
    Well, frankly, I don’t really want a revocation list, and I don’t really want signed extensions in the first place. It’s my browser, and it’s not Mozilla’s business to decide what I install on my browser. And I most definitely don’t want my browser to fail into an unsafe configuration.
overgard 7y ago
This is bad design. Installed software shouldn't just stop working because the clock ticked. (And yes, I know browsers should stay up to date etc. etc., but come on, no software should just stop functioning because of a calendar) And to the downvoters: doesn't this entire fiasco ENTIRELY PROVE MY POINT?
- wool_gather 7y ago
  No, I totally agree with that (I just edited to expand on this point). It was a bad user experience.
  - overgard 7y ago
    Well, I disagree that it's a UX issue. The problem is they shouldn't be expiring local software at all. If it was trustworthy at the time of install, why should the calendar date matter? If users don't want to stay up to date, that may be unwise, but that's there call.
    - rincebrain 7y ago
      Because if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.
      - overgard 7y ago
        Revocation should handled differently than expiration. Two entirely separate things.
      - nitrogen 7y ago
        But revocation is different from expiration. If you're worried about a cert being compromised long after expiration and used to back-date a signature, you can show a warning, add a second signature with a local key at time of installation, use a blockchain to prove age, have a timestamping service generate its own signature at time of generation, etc.

rauhl 7y ago

Clearly, downstream distributors need to create a patch which causes their distributes Firefox builds to only check certificates on add-on installation (and to check revocations too, sure): it should never be possible for a browser to fail into an unsafe configuration.

wool_gather 7y ago
What's the difference to the user between "to check revocations too, sure" and what happened?
- the8472 7y ago
  checking revocations lists != certificate expiry
  - wool_gather 7y ago
    At a the technical level of cert handling, yes. To the user? Not so sure.
  - dwaite 7y ago
    Revocation lists are often tied to certificate expiry, purging entries that are no longer valid due to expiry.
    - the8472 7y ago
      No, revocation lists are orthogonal, often used to invalidate a certificate before it expires.
- diplocorp 7y ago
  revocation != expiry
Xylakant 7y ago
Cert expiration is the only safe revocation. You cannot rely on revocation lists in many settings. Access to them might be maliciously blocked or, if locally kept, tampered with. The list could for example be replaced with an older one, which would circumvent signing the list unless the signature contains an expiration date and then you’re back to “oh, list expired, how do we fail?” You cannot rely on check at extension install. That would assume that all malicious extensions are installed via FF proper. Oracles crapware bundling in the Java installer taught us that’s now how things go. You cannot remember the trust flag when an extension is installed via FF as a crapware installer could just set the trust flag, too. After all, that storage would be accessible, too. You cannot sign or encrypt that trust storage as the key material would have to be kept locally and would be accessible to the crapware installer.
- rauhl 7y ago
  Well, frankly, I don’t really want a revocation list, and I don’t really want signed extensions in the first place. It’s my browser, and it’s not Mozilla’s business to decide what I install on my browser. And I most definitely don’t want my browser to fail into an unsafe configuration.

overgard 7y ago

This is bad design. Installed software shouldn't just stop working because the clock ticked. (And yes, I know browsers should stay up to date etc. etc., but come on, no software should just stop functioning because of a calendar) And to the downvoters: doesn't this entire fiasco ENTIRELY PROVE MY POINT?

wool_gather 7y ago
No, I totally agree with that (I just edited to expand on this point). It was a bad user experience.
- overgard 7y ago
  Well, I disagree that it's a UX issue. The problem is they shouldn't be expiring local software at all. If it was trustworthy at the time of install, why should the calendar date matter? If users don't want to stay up to date, that may be unwise, but that's there call.
  - rincebrain 7y ago
    Because if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.
    - overgard 7y ago
      Revocation should handled differently than expiration. Two entirely separate things.
    - nitrogen 7y ago
      But revocation is different from expiration. If you're worried about a cert being compromised long after expiration and used to back-date a signature, you can show a warning, add a second signature with a local key at time of installation, use a blockchain to prove age, have a timestamping service generate its own signature at time of generation, etc.