Open Bug 1549018 Opened 7 months ago Updated 2 months ago

create a transition plan to prepare for the add-on signing root expiring in 2025

Categories

(Toolkit :: Add-ons Manager, task, P2)

task

Tracking

()

People

(Reporter: dveditz, Assigned: jvehent)

References

(Blocks 1 open bug)

Details

Inspired by bug 1548973, the add-on signing root is going to expire in 2025 so we need a transition plan ("Not After : Mar 14 22:53:57 2025 GMT"). Ideally we don't want to break existing signed add-ons so I think that means creating a new security/apps/addons-public.crt with the same issuer name and key.

Any old Firefox that has not gotten the updated cert will have all its add-ons fail so we need to transition well before the expiration date (couple of years?) so that long-lived ESRs and watershed releases have the future cert in time.

2021 or 2022 might be a good time to do this.

Flags: needinfo?(jvehent)
Flags: needinfo?(dkeeler)

Hi,

What about using a addon timestamp so signatures and certificates can't expire even when never updated (because they maybe still work despite a not so available maintainer) ?
But the timestamp might have to be signed too then ...

I think this is what Windows does to check drivers signatures.

Presumably we'll need to update the new intermediate at that time as well (it expires around the same time as the root now, I believe).
In any case, I think comment 0 outlines a good approach (unless we want to have a new key? not sure what best practices are about that (or will be at that time)).

Flags: needinfo?(dkeeler)
Priority: -- → P2

This is possibly a dumb question, but why does the signing key need to have an expiration date at all (or one more recent than, say, 2200)? If the plan is already to replace these keys every few years, than the usual motivation for having certificates expire (as I understand it: if malware manages to get a hold of a very old private key, you don't want them to be able to spoof your current system) doesn't apply to any browser that's been updated in the past few years. The main difference is that people powering on computers that haven't been used in a decade won't suddenly find that none of their add-ons work; instead, they might theoretically be vulnerable to malware-installed addons if the malware author has access to a private key from the appropriate date range. IMO, that's a reasonable trade-off.

Since this has come up a couple of times I should clarify that I'm not presupposing that signed add-ons will work the same way in the future. We could "transition" to something that doesn't require certificates at all, I suppose (signed .MAR files don't use certificates, for example). But we will still need a transition plan for how to handle old add-ons and old clients and how to get users on to the new system.

Blocks: 1555978

Proposal: As a lightweight failsafe we can act on today, we could add a test to somewhere appropriate that checks the date and fails with an informative message if the date is later than, say, October 1st, 2024.

(In reply to Mike Hoye [:mhoye] from comment #5)

Proposal: As a lightweight failsafe we can act on today, we could add a test to somewhere appropriate that checks the date and fails with an informative message if the date is later than, say, October 1st, 2024.

Something along those lines is probably a good idea, but 2024 is really too late. There are more options on the table if we have at least a full ESR cycle of lead time.

I'm working on this with mgoodwin in Q4. Will have a proposal to present to this group by Berlin.

Assignee: nobody → jvehent
Flags: needinfo?(jvehent)
You need to log in before you can comment on or make changes to this bug.