3 ms·
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
by overgard 8y 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 8y agoBecause if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.
- overgard 8y agoRevocation should handled differently than expiration. Two entirely separate things.
- nitrogen 8y agoBut 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.
- rincebrain 8y agoSure, my point was mostly that there are reasonable cases in which one might want to evaluate the signing of an addon after the fact.
- the8472 8y agoThat might make sense for TLS certificates where the server can change their content on a whim. A signed and installed addon has been trusted possibly for years, the need for sudden revocation is not dire enough compare to the price you have to pay for that (this failure, always-online requirement)