1085273 - v2 mac signing still not working on partner repacks

Status: RESOLVED FIXED

(Release Engineering :: Release Automation, defect)

Description

[Hector Zhao [:hectorz]]

+++ This bug was initially created as a clone of Bug #1048890 +++

(In reply to Hector Zhao [:hectorz] from comment #7)
> IIUC, in bug 1047738, the new home for distribution directory is
> Contents/Resources instead of MozResouces?

Confirmed by QA in Beijing office, excerpt from mail:
> Tested the partner package[1], the message “”Firefox” is damaged and can’t be opened. You should move it to Trash.” was displayed.
> 
> Set 'Allow apps download from: Anywhere’ in ’Security&Privacy’, it can be opened and all the customized contents in distribution were not applied.
> 
> [1]: https://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/34.0b1-candidates/build2/partner-repacks/bing/mac/en-US/

Comment 1

[[e-mail] (:bhearsum)]

It looks like it's still using Contents/MacOS:
2014-10-15 00:06:52,492 - Executing cp -r /builds/slave/rel-m-beta-osx64_partner_rpk-0/partner-repacks/scripts/./../partners/1und1/distribution stage/Firefox.app/Contents/MacOS
2014-10-15 00:06:52,493 - in /builds/slave/rel-m-beta-osx64_partner_rpk-0/partner-repacks/scripts/repacked_builds/34.0b1/build2/partner-repacks/1und1/mac/de/working

Which is probably because these scripts didn't get updated after MozResources was dropped, I still see this code:
   417     def copyFiles(self):

   418         if path.exists(path.join("stage", "Firefox.app", "MozResources")):

   419             target_dir = path.join("stage", "Firefox.app", "MozResources")

   420         else:

   421             target_dir = path.join("stage", "Firefox.app", "Contents", "MacOS")

Comment 2

[[e-mail] (:bhearsum)]

Attachment: use Contents/Resources instead of MozResources

Comment 3

[[e-mail] (:bhearsum)]

Comment on attachment 8507885 [details] [diff] [review]
use Contents/Resources instead of MozResources

Oops, spohl pointed out that Resources exists no matter what. New patch coming.

Comment 4

[[e-mail] (:bhearsum)]

Attachment: check for Contents/Resources/defaults instead

I was thinking of looking for distribution, but I don't think it exists at the time this code runs. But we're just looking for new vs. old style layout, so this should be fine.

Comment 5

[Stephen A Pohl [:spohl]]

Comment on attachment 8507889 [details] [diff] [review]
check for Contents/Resources/defaults instead

Review of attachment 8507889 [details] [diff] [review]:
-----------------------------------------------------------------

::: scripts/partner-repacks.py
@@ +416,5 @@
>          os.remove("stage/ ")
>  
>      def copyFiles(self):
> +        if path.exists(path.join("stage", "Firefox.app", "Contents", "Resources", "defaults")):
> +            target_dir = path.join("stage", "Firefox.app", "Contents", "Resources", "defaults")

I think you wanted target_dir to point to Contents/Resources here. r+ with that.

Comment 6

[[e-mail] (:bhearsum)]

Comment on attachment 8507889 [details] [diff] [review]
check for Contents/Resources/defaults instead

(In reply to Stephen Pohl [:spohl] from comment #5)
> Comment on attachment 8507889 [details] [diff] [review]
> check for Contents/Resources/defaults instead
> 
> Review of attachment 8507889 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> ::: scripts/partner-repacks.py
> @@ +416,5 @@
> >          os.remove("stage/ ")
> >  
> >      def copyFiles(self):
> > +        if path.exists(path.join("stage", "Firefox.app", "Contents", "Resources", "defaults")):
> > +            target_dir = path.join("stage", "Firefox.app", "Contents", "Resources", "defaults")
> 
> I think you wanted target_dir to point to Contents/Resources here. r+ with
> that.

Oops, yeah. Thanks for catching this, too. I landed with that fixed.

Comment 7

[[e-mail] (:bhearsum)]

This still isn't working. I think there's a larger problem here: the partner repack script uploads a *dmg*, not a .app. I think we need more work here to make this work.

Surprisingly, the signing server doesn't blow up when you ask it to sign a dmg file.

Comment 8

[[e-mail] (:bhearsum)]

Apparently signing a dmg is a thing with codesign, so that explains why that didn't fail:
[[e-mail] ~]$ codesign -s Mozilla -fv --keychain /builds/signing/rel-key-signing-server/secrets/dmg/signing.keychain --requirement '=designated => ( (anchor apple generic and certificate leaf[field.1.2.840.113635.100.6.1.9] ) or (anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] and certificate leaf[field.1.2.840.113635.100.6.1.13] and certificate leaf[subject.OU] = "43AQ936H96"))' Firefox\ 34.0b2.dmg
Firefox 34.0b2.dmg: signed generic [Firefox 34.0b2]


I'll try to get a patch ready for this today - I'd like to fix it before 34.0b3.

Comment 9

[[e-mail] (:bhearsum)]

Attachment: support internal + external signing

I tested this out on Linux, Mac, and Windows. The Mac repacks got signed properly - to the point where codesign -vvvv likes them again. Linux and Windows were signed as normal.

Comment 10

[[e-mail] (:bhearsum)]

Comment on attachment 8508886 [details] [diff] [review]
support internal + external signing

OK, this should work for 34.0b3, which starts on Thursday.

Comment 11

[Nick Thomas [:nthomas] (UTC+12)]

Attachment: Fix up signing of older mac builds

For 33.0.1 we have mac partner repack logs like this:
2014-10-21 23:09:44,429 - e5f90d63339fface100f35476591743372369cd0: processing Firefox.app.tar.gz on https://mac-v2-signing1.srv.releng.scl3.mozilla.com:9120
2014-10-21 23:09:44,453 - e5f90d63339fface100f35476591743372369cd0: uploading for signing
2014-10-21 23:09:53,815 - e5f90d63339fface100f35476591743372369cd0: processing Firefox.app.tar.gz on https://mac-v2-signing1.srv.releng.scl3.mozilla.com:9120
2014-10-21 23:10:54,838 - e5f90d63339fface100f35476591743372369cd0: processing Firefox.app.tar.gz on https://mac-v2-signing1.srv.releng.scl3.mozilla.com:9120
2014-10-21 23:11:55,860 - e5f90d63339fface100f35476591743372369cd0: processing Firefox.app.tar.gz on https://mac-v2-signing1.srv.releng.scl3.mozilla.com:9120
2014-10-21 23:12:56,899 - e5f90d63339fface100f35476591743372369cd0: processing Firefox.app.tar.gz on https://mac-v2-signing1.srv.releng.scl3.mozilla.com:9120
2014-10-21 23:13:24,900 - e5f90d63339fface100f35476591743372369cd0: processing Firefox.app.tar.gz on https://mac-v2-signing1.srv.releng.scl3.mozilla.com:9120
....

On the signing server there is a rc of 1 from signscript. I think we're doing dmgv2 signing on the wrong file layout, so this avoids that, but I'm unsure if this is the right diagnosis & fix.

Comment 12

[[e-mail] (:bhearsum)]

Comment on attachment 8509257 [details] [diff] [review]
Fix up signing of older mac builds

Review of attachment 8509257 [details] [diff] [review]:
-----------------------------------------------------------------

I landed and retagged for this.

Comment 13

[[e-mail] (:bhearsum)]

This is working again for old style mac builds:
[[e-mail] ~]$ curl http://ftp.mozilla.org/pub/mozilla.org/firefox/candidates/33.0.1-candidates/build1/partner-repacks/gmx/mac/en-US/Firefox%2033.0.1.dmg > firefox.dmg
[[e-mail] ~]$ hdiutil attach firefox.dmg 
[[e-mail] ~]$ codesign -vvv /Volumes/Firefox/Firefox.app/
/Volumes/Firefox/Firefox.app/: valid on disk
/Volumes/Firefox/Firefox.app/: satisfies its Designated Requirement


Sorry for all the fallout from this, and thanks to everyone for helping out!