806280 - l10n stub installers on latest-mozilla-aurora-l10n and latest-mozilla-central-l10n need to be signed builds

Status: VERIFIED FIXED

(Release Engineering :: General, defect, P1)

Description

[Jason Smith [:jsmith]]

In checking the l10n stub installer builds being served on each l10n directory for aurora and nightly, I noticed that the stub installer builds are not signed, even the full installer builds are signed. We need to be consistent in making sure that the stub installer builds are also getting signed for the various l10n stub installer builds in the Aurora and Nightly directories respectively.

Comment 1

[Jason Smith [:jsmith]]

Tacking on tracking 18 and 19 because we need signed l10n builds.

Comment 2

[Alex Keybl [:akeybl]]

It'd be great to get this working on the order of days, since QA has called this out as a test day blocker (and I tend to agree). Since we'd like to get a test day in place before FF18 (along with the l10n stub) moves to Beta mid-November, a hard deadline would probably be a week from today. Jason - let me know if that lines up with your expectations.

Comment 3

[Jason Smith [:jsmith]]

(In reply to Alex Keybl [:akeybl] from comment #2)
> It'd be great to get this working on the order of days, since QA has called
> this out as a test day blocker (and I tend to agree). Since we'd like to get
> a test day in place before FF18 (along with the l10n stub) moves to Beta
> mid-November, a hard deadline would probably be a week from today. Jason -
> let me know if that lines up with your expectations.

Yup, that aligns with my understanding.

Comment 4

[Rail Aliiev [:rail]]

I found a couple other issue with l10n repacks. :/

The following locales still use Firefox branding instead of Nightly.

 be
 bn-IN
 el
 en-GB
 eo
 gd
 lv
 nb-NO
 pa-IN
 ro
 te
 th
 tr
 zh-TW

At the same time the properly branded locales are around 600k vs 200k.

Comment 5

[Chris AtLee [:catlee]]

That's bug 804090, which _should_ be fixed for today's stub installers off of m-c.

Comment 6

[Rail Aliiev [:rail]]

(In reply to Chris AtLee [:catlee] from comment #5)
> That's bug 804090, which _should_ be fixed for today's stub installers off
> of m-c.

Yeah, looks like the locales with not nightly branding are built yesterday.

In any case, the bump in the file size sucks. :/

Anyways, I'm testing a fix for the initial issue ATM.

Comment 7

[Rail Aliiev [:rail]]

Attachment: sign stub.exe inplace

It turns out that we sign the stub.exe file (http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/toolkit/mozapps/installer/windows/nsis/makensis.mk#l75
) after we copy it to $(DIST)/... (http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/toolkit/mozapps/installer/windows/nsis/makensis.mk#l69), what works fine for en-US builds.

L10N repacks for windows have a hook to remove some localizable files from $(DIST) and copy the regenerated ones over:
http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/browser/locales/Makefile.in#l65

The solution here is signing stub.exe file exactly the same way as we sign setup.exe here:
http://hg.mozilla.org/mozilla-central/file/7a52ba9b1542/toolkit/mozapps/installer/windows/nsis/makensis.mk#l55

I tested the patch in staging and l10n repack went fine, just need to confirm that the patch doesn't break the en-US build:
https://tbpl.mozilla.org/?tree=Try&rev=c72dec600eb8

Comment 8

[Rail Aliiev [:rail]]

(In reply to Rail Aliiev [:rail] from comment #7)
> I tested the patch in staging and l10n repack went fine, just need to
> confirm that the patch doesn't break the en-US build:
> https://tbpl.mozilla.org/?tree=Try&rev=c72dec600eb8

http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-c72dec600eb8/try-win32/firefox-19.0a1.en-US.win32.installer-stub.exe looks fine to me.

Comment 9

[Chris AtLee [:catlee]]

Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

Looks good to me.

Comment 10

[Rail Aliiev [:rail]]

Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

http://hg.mozilla.org/mozilla-central/rev/3d1432add5d8

Comment 11

[Jason Smith [:jsmith]]

Is this RESOLVED FIXED since there's a check in or is there more work to be done here?

Comment 12

[Rail Aliiev [:rail]]

(In reply to Jason Smith [:jsmith] from comment #11)
> Is this RESOLVED FIXED since there's a check in or is there more work to be
> done here?

I think we need to uplift this to aurora as well. Let me nomnomnom it. :)

Comment 13

[Rail Aliiev [:rail]]

Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

The patch is a blocker for l10n stub deployment. Would be great to uplift it to aurora.

Bug caused by (feature/regressing bug #): initial implementation
User impact if declined: all l10n stub installer consumers
Testing completed (on m-c, etc.): tested on m-c
Risk to taking this patch (and alternatives if risky): low
String or UUID changes made by this patch: None

Comment 14

[Alex Keybl [:akeybl]]

Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

[Triage Comment]
Thanks for fixing! I believe l10n stub testing will now be unblocked.

Comment 15

[Rail Aliiev [:rail]]

Comment on attachment 677121 [details] [diff] [review]
sign stub.exe inplace

http://hg.mozilla.org/releases/mozilla-aurora/rev/2f36bbb7ea8f