4 ms·
No, I totally agree with that (I just edited to expand on this point). It was a bad user experience.
by 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 agoWell, 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 agoBecause if the cert is (for example) actively revoked, that probably means you should stop trusting things signed by it in the past.
- overgard 7y agoRevocation should handled differently than expiration. Two entirely separate things.
- nitrogen 7y 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 7y 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 7y 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)