1338271 - Retest manual dmg signing

Status: RESOLVED FIXED

(Release Engineering :: Release Automation: Other, defect, P2)

Description

[Justin Wood (:Callek)]

This is related to https://trello.com/c/OiAtiv4k/37-mac-re-test-signing-once-ted-has-new-version-of-tool

We explicitly were postponing the rest of the test until the new libdmg was built because of it not extracting the +x bit. This involves unpacking the dmg and then signing the .App (as a tarball) and then repacking the dmg.

Comment 1

[Kim Moir [:kmoir] ET]

Ted, I'm filling in for Callek on this bug while he's away.  Is there a bug which tracks the new version of the libdmg being built?  I looked but couldn't find a corresponding bug.

Comment 2

[Kim Moir [:kmoir] ET]

nevermind, I just found bug 1337393

Comment 3

[Kim Moir [:kmoir] ET]

Okay these are the steps I used to test this

Ran a try build with a patch to stop it
https://treeherder.mozilla.org/#/jobs?repo=try&revision=1cda7169bd7c771fd859ec0d793936bc70ba8e05
Loaned myself a one-click loaner from that build
updated the GECKO env variables to point to a revision that didn't have the patch that stopped the build
ran the build until the tooltool binaries for the dmg tools were checked out
cd /home/worker/workspace/build/src/dmg
wget a recent tc macosx dmg build from inbound to the loaner
https://queue.taskcluster.net/v1/task/A_vHMbPuTUqdz3TV4LKw7g/runs/0/artifacts/public/build/target.dmg
./dmg extract target.dmg firefox.hfs
mkdir /tmp/extract
./hfsplus firefox.hfs extractall / "/tmp/extract"

Looks like the files have execute permission
[root@taskcluster-worker dmg]# ls -l /tmp/extract/Nightly.app/Contents/MacOS
total 140032
drwxr-xr-x 3 root root      4096 Feb 14 15:55 crashreporter.app
-rwxr-xr-x 1 root root     17584 Feb 14 15:55 firefox
-rwxr-xr-x 1 root root     17584 Feb 14 15:55 firefox-bin
-rwxr-xr-x 1 root root    570604 Feb 14 15:55 libfreebl3.dylib
-rwxr-xr-x 1 root root     93180 Feb 14 15:55 liblgpllibs.dylib
-rwxr-xr-x 1 root root   2313216 Feb 14 15:55 libmozavcodec.dylib
-rwxr-xr-x 1 root root    256888 Feb 14 15:55 libmozavutil.dylib
-rwxr-xr-x 1 root root    187896 Feb 14 15:55 libmozglue.dylib
-rwxr-xr-x 1 root root   3033724 Feb 14 15:55 libnss3.dylib
-rwxr-xr-x 1 root root    647140 Feb 14 15:55 libnssckbi.dylib
-rwxr-xr-x 1 root root    170164 Feb 14 15:55 libnssdbm3.dylib
-rwxr-xr-x 1 root root      8240 Feb 14 15:55 libplugin_child_interpose.dylib
-rwxr-xr-x 1 root root    343808 Feb 14 15:55 libsoftokn3.dylib
-rwxr-xr-x 1 root root     11040 Feb 14 15:55 pingsender
drwxr-xr-x 3 root root      4096 Feb 14 15:55 plugin-container.app
drwxr-xr-x 3 root root      4096 Feb 14 15:55 updater.app
-rwxr-xr-x 1 root root 135687252 Feb 14 15:55 XUL

It was indicated in https://bugzilla.mozilla.org/show_bug.cgi?id=1337393#c0 that the problem with the previous version of the libraries was that they weren't preserving execute permissions.

Comment 4

[(not currently active) Ted Mielczarek]

Yeah, that looks sensible. I think Callek had done a manual repack somehow where he unpacked a dmg like that, then repacked it somehow and tested the resulting dmg on a Mac.

Comment 5

[Kim Moir [:kmoir] ET]

I talked to Callek about this yesterday and he said that since the permissions looked good we are fine to close this bug.