Closed Bug 1197876 Opened 5 years ago Closed 1 year ago

[meta] Require signing for locale packs

Categories

(Toolkit :: Add-ons Manager, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
firefox40 --- wontfix
firefox41 - wontfix
firefox42 - wontfix
firefox43 + wontfix
firefox60 + wontfix
firefox61 --- affected

People

(Reporter: mossop, Unassigned)

References

Details

(Keywords: meta, sec-want, Whiteboard: [releng])

Locale packs are capable of injecting script into chrome documents (see bug 1193926 comment 9) and so we must require them to be signed.
Assignee: nobody → dtownsend
Depends on: 1198425
What about Nightly language packs? Locale teams usually do with aurora(sometimes not in time) and for nightly I've seen many people translating by themselves(like me). Have you ever thought about them? Or maybe you should force l10n teams do with nightly but not aurora.
Dave, do you think we will fix this in FF41 time frame? If not, I would like to un-track for 41 and leave tracking for 42, 43.
Flags: needinfo?(dtownsend)
Apparently we're not doing this for older language packs so we wouldn't be able to uplift this anyway
What Firefox version should we start requiring this?
Flags: needinfo?(kmaglione+bmo)
Note that this means that all the locale packs we generate during the normal Firefox build process will stop working the way they did before and need to be looped through AMO to work. Also, a lot of Linux distros provide L10n for their release builds only through locale packs and they build themselves so those packs are probably unsigned and will stop working. In other words, we need to make quite some noise around this if we do it.
It's hard to say. We haven't come up with a plan for signing locale packs for betas yet, so requiring signing on non-release builds seems like a bad idea. And we don't even build locale packs for nightly or Aurora, so it's going to be hard to do smoke tests.

Given comment 7, I think we should probably try to reach out to people who might be affected before we make a decision. And we definitely need to figure out what we're going to do about language packs for betas.
Flags: needinfo?(kmaglione+bmo)
In which case until there is a plan for when this needs to happen I'm going to re-assign this. I'm happy to do the patch when we know when we want it, it will be pretty simple.
Assignee: dtownsend → kev
Kris, any news on what we are planning here? Thanks.
Flags: needinfo?(kmaglione+bmo)
It's up to kev, at this point. I can answer any specific technical questions, but the decisions aren't mine to make.
Flags: needinfo?(kmaglione+bmo)
Kev, is this still an issue for 43? 
I'm assuming it isn't planned to affect 43 here.
Flags: needinfo?(kev)
We should do this, but I think we've missed the boat for 43. I need to find out how locale packs are generated at Mozilla at least and make sure when we land code for this we've got a plan in place.
Assignee: kev → amckay
Flags: needinfo?(kev)
Confirmed that language packs on AMO for 42+ are all signed as per bug 1198425.
So as I understand it, this is ok on release, and we don't have concrete plans yet for pre-release channels.   
Once we do have plans, please re-nominate this for tracking or let release management know it's moving forward.
Linux distros feel like the most challenging user right now.

For localizers, being able to test on aurora is important, and we're keeping the pref there to allow developers to test their add-ons, right?
(In reply to Axel Hecht [:Pike] from comment #16)
> Linux distros feel like the most challenging user right now.
> 
> For localizers, being able to test on aurora is important, and we're keeping
> the pref there to allow developers to test their add-ons, right?

Yes, on Aurora we will allow users to turn off the pref.
Whiteboard: [releng]
Blocks: 1240191
Keywords: sec-want
Blocks: 1244131
See Also: → 1388143
Based on the conversation in bug 1388143, could we get signed language packs in the build for 59 so that we can flip the flag to require this?
Flags: needinfo?(jlund)
callek is in charge of all things l10n for ReleaseEngineering.

callek, can you have a look at this, scoping out requirements from us, the automation solution, and coordination with teams involved?

Some open questions needed to be answered:

- how and where this is still needed
- how it differs from esr52 (the langpack format)
- how we can bake this effort into esr59 tcmigration timeline.
- can we sign the langpacks after we build, through AMO? Skipping any work needed on our signing servers.
- How do we enforce they are signed? Do we need build sys support?
- For esr 59.0.0 what's the minimum needed? Can we add enforced signing support but manually sign initially?
Flags: needinfo?(jlund) → needinfo?(bugspam.Callek)
(In reply to Jordan Lund (:jlund) from comment #19)
> callek is in charge of all things l10n for ReleaseEngineering.
> 
> callek, can you have a look at this, scoping out requirements from us, the
> automation solution, and coordination with teams involved?
> 
> Some open questions needed to be answered:

Taking some of those questions.

> - how and where this is still needed
> - how it differs from esr52 (the langpack format)

They're just regular web extension zip files, with xpi extension. And we want them to be signed.

> - how we can bake this effort into esr59 tcmigration timeline.
> - can we sign the langpacks after we build, through AMO? Skipping any work
> needed on our signing servers.

I personally don't like the idea of having things on ftp that people can't use.
Also, at least for automated generation of snaps, we'll want the signing process to be part of the task graph, I think.
And yes, the language packs that are part of the snap need to be signed, too.

> - How do we enforce they are signed? Do we need build sys support?
> - For esr 59.0.0 what's the minimum needed? Can we add enforced signing
> support but manually sign initially?
Depends on: 1426181
Thanks Axel for that.

I've created bug 1426181 to track releng/automation work.
Flags: needinfo?(bugspam.Callek)
Blocks: 1438246
Adding conversation to Bug....

We want to use the existing pref for the real implementation to control language pack signing requirement, the same as other add-on signing (xpinstall.signature.required).  

But if we only use that existing pref (xpinstall.signature.required) for testing in Beta - as soon as the patch lands it requires language packs be signed.  

That might not be bad in Beta - but if for some reason release engineering doesn't get the back end together in time (for end to end testing)... my concern (which may be misplaced) is there is no fall back option to ignore the patch (which would continue to allow unsigned language packs).

We can't flip the xpinstall.signature to false to ignore the patch - because that would allow ALL unsigned add-ons.  

I didn't know if there was a possibility of a pref to ignore the patch if we don't make it for 60?
Assignee: amckay → aswan
Flags: needinfo?(krupa.mozbugs)
Flags: needinfo?(ddurst)
Flags: needinfo?(aswan)
I thought what we talked about today is creating a (possibly temporary?) new preference so that QA can starting testing now (with language packs signed in the AMO staging or dev environment since signed language packs for 60 don't exist yet).
When QA signs off we can either make that pref work just like xpinstall.signatures.required (ie only honored on non-release branches), or remove that pref and fold that behavior into xpinstall.signatures.required.
Flags: needinfo?(aswan)
Exactly aswan said is perfect.  Sorry I was confusing.
Depends on: 1444487
Flags: needinfo?(ddurst)
This is currently being tested.
Flags: needinfo?(krupa.mozbugs)
unassigning myself from the tracking bug
Assignee: aswan → nobody
Keywords: meta
Depends on: 1454141
Setting 60 to wontfix as I believe 1454141 is hoping to land for 61.
:aswan this is done, right?
Flags: needinfo?(aswan)
Depends on the scope I guess.  We're not requiring signed language packs on dev edition yet.  Kev, is that something worth keeping this open for?
Flags: needinfo?(aswan) → needinfo?(kev)

Is dev edition still a pending issue here?

Flags: needinfo?(kev-bugzilla) → needinfo?(aswan)
Summary: Require signing for locale packs → [meta] Require signing for locale packs

I don't remember what the issue was for dev edition. We allow unsigned addons of other types on dev edition with a flip of xpinstall.signatures.required. We do the same for langpacks but with a different pref (extensions.langpacks.signatures.required).
I'm going to close this meta bug, if there was some other dev edition issue that wasn't well captured here it should probably just be a new bug.

Status: NEW → RESOLVED
Closed: 1 year ago
Flags: needinfo?(aswan)
Resolution: --- → FIXED
Summary: [meta] Require signing for locale packs → Require signing for locale packs
Summary: Require signing for locale packs → [meta] Require signing for locale packs
You need to log in before you can comment on or make changes to this bug.