Closed Bug 974570 Opened 7 years ago Closed 7 years ago

Sign MAR files on all platforms


(Firefox Build System :: General, defect)

Not set


(Not tracked)



(Reporter: bbondy, Assigned: bbondy)




(1 file, 1 obsolete file)

Currently MAR files are only signed on Windows. 

Doing a signmar -T firefox-30.0a1.en-US.win32.complete.mar
Reports 1 signature found.

Doing a signmar -T firefox-30.0a1.en-US.mac.complete.mar
Reports 0 signature found.

In preparation for the work tracked in bug 973933, could we sign MARs on all platforms?
Please use the same keys as you do on Windows for this.
Checks for signatures are only enabled on Windows at the moment, but after the tracking bug dependencies land, it will be enabled on all platforms.
Component: Releases → General Automation
QA Contact: rail → catlee
Looks like a Build Config issue:
* mar files are signed if MOZ_SIGN_PACKAGE_CMD is set
* which depends on MOZ_EXTERNAL_SIGNING_FORMAT being set at
* which is defined at
Component: General Automation → Build Config
Product: Release Engineering → Core
QA Contact: catlee
So I would just need to set 

For both Darwin and Linux?
<nthomas	catlee>: do you know what the right answer is on bug 974570 ? signcode doesn't seem right
       <catlee>: fix the makefiles to not depend indirectly on EXTERNAL_SIGNING_FORMAT
Great thanks for the info, I'll test out a fix and submit a patch for review if it works.
Attached patch signcmd.diff (obsolete) — Splinter Review
Actually I'm really not confident that this is right so I'll go for feedback first before pushing to oak for testing.
Attachment #8378660 - Flags: feedback?(catlee)
Comment on attachment 8378660 [details] [diff] [review]

Review of attachment 8378660 [details] [diff] [review]:

::: toolkit/mozapps/installer/
@@ -563,1 @@

I'm not sure this is really the right way to do this, even if it works.

Maybe better is to modify or line 66 to act in if MOZ_SIGN_CMD is set, use it directly, like $(MOZ_SIGN_CMD) -f mar .../complete.mar
Attachment #8378660 - Flags: feedback?(catlee) → feedback-
Attached patch signcmd.diffSplinter Review
Like this?
Attachment #8378660 - Attachment is obsolete: true
Attachment #8379016 - Flags: feedback?(catlee)
Comment on attachment 8379016 [details] [diff] [review]

Review of attachment 8379016 [details] [diff] [review]:

yeah, that looks more promising!
Attachment #8379016 - Flags: feedback?(catlee) → feedback+
OK thanks, I'll test it out and then mark it for review
So for the nightly which happened last night (self serve ones aren't working) here:

It looks like the linux mars are being signed now.
But there is no OSX mar available there, even know tbpl shows a successful nightly here:
Oh whoops. Rev 4102831c51b4 was built on the 19th (links in comment #12). 1c875d373815 is the current tip, and failed in the mac build:
2014-02-21 05:04:19,208 - 1559ea42e979bc233cbb37c25ca8348e807b8532: processing ../../dist/update//firefox-30.0a1.en-US.mac.complete.mar on
2014-02-21 05:04:19,241 - 1559ea42e979bc233cbb37c25ca8348e807b8532: uploading for signing
2014-02-21 05:04:28,976 - 1559ea42e979bc233cbb37c25ca8348e807b8532: error uploading file for signing: 400 File too large

It's the regular 72M size, we're just hitting this limit set in the signing server:
Depends on: 975678
Thanks Nick!
Attachment #8379016 - Flags: review?(catlee)
Comment on attachment 8379016 [details] [diff] [review]

Review of attachment 8379016 [details] [diff] [review]:

Let's get some eyes from the build system guys on this too.
Attachment #8379016 - Flags: review?(ted)
Attachment #8379016 - Flags: review?(catlee)
Attachment #8379016 - Flags: review+
Attachment #8379016 - Flags: review?(ted) → review+
Assignee: nobody → netzen
This is another bug I'd like to have tested before the nightly mars go out to everyone. Is that possible? I think you're doing this soon for rstrong in another bug.  I'd like to make sure that all platforms can apply the MAR files that are served when they are signed.
Flags: needinfo?(nthomas)
Sure, we can do that for mozilla-central if you want, probably better to do it on a separate day from rstrong. Does Oak not provide the testing you need though ? AFAIK we have the branch and update server set up to offer updates on the nightly-oak channel.
Flags: needinfo?(nthomas)
Oak currently has the MAR verification changes on it, and I wanted to test it without that on it.  I could rebase it to m-c tip and then re-push everything I guess.  I think I'll do that to avoid making others do work, thanks for the suggestion.
Ah, the devil is in the details. Happy to do the update server lock/unlock for nightly whenever.
FYI I tested this on Oak as per the above plan and this is working correctly.
I also verified that each full and partial MAR for each platform is being signed now.

I'll be pushing this out to mozilla-inbound when the tree opens back up.  So it should be on tomorrow's nightly.  Just a heads up in case there are any problems with updates being consumed.
Looks like MARs are getting signed on Mac and Linux now:
2014-03-13 08:03:11,718 - 02e7cda4da7f306dec98849c26b741c644e0b709: processing ../../dist/update//firefox-30.0a1.en-US.linux-i686.complete.mar on
2014-03-13 08:03:11,995 - 02e7cda4da7f306dec98849c26b741c644e0b709: uploading for signing
2014-03-13 08:05:06,746 - e7672b9a3454a476e3cf36c1633d711b5a918a80: processing ../../dist/update/firefox-30.0a1.en-US.linux-i686.partial.20140312030201-20140313030202.mar on
2014-03-13 08:05:06,955 - e7672b9a3454a476e3cf36c1633d711b5a918a80: uploading for signing

2014-03-13 04:14:56,770 - 8455ff6be21657e7701df3c6bf8ebd04a60cae11: processing ../../dist/update//firefox-30.0a1.en-US.mac.complete.mar on
2014-03-13 04:14:57,093 - 8455ff6be21657e7701df3c6bf8ebd04a60cae11: uploading for signing
2014-03-13 04:20:15,405 - 5e92078ee44eea470d925fa7b18835aa7574c553: processing ../../dist/update/firefox-30.0a1.en-US.mac.partial.20140312030201-20140313030202.mar on
2014-03-13 04:20:15,791 - 5e92078ee44eea470d925fa7b18835aa7574c553: uploading for signing
Thanks for confirming Ben
Duplicate of this bug: 730824
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.