https://developer.apple.com/library/prerelease/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/OSXv10.html, under “Security and Privacy Enhancements”, says:

> Starting in OS X v10.12, you can no longer provide external code or
> data alongside your code-signed app in a zip archive or unsigned disk
> image. An app distributed outside the Mac App Store runs from a
> randomized path when it is launched and so cannot access such external
> resources. To provide secure execution, code sign your disk image
> itself using the codesign tool, or distribute your app through the Mac
> App Store. For more information, see the updated revision to OS X Code
> Signing In Depth.

The “updated revision” is https://developer.apple.com/library/prerelease/content/technotes/tn2206/_index.html, which now contains a “Signing Disk Images” section:

> Disk images can be signed using the codesign tool starting with OS X
> v10.11.5. This allows the entire disk image to be validated by
> Gatekeeper the first time it is mounted.
>
> Gatekeeper will validate the contents of the disk image as well.
>
> On macOS Sierra and later, spctl can be used to assess a disk image's
> signature, like this:
>
> $ spctl -a -t open --context context:primary-signature -v MyImage.dmg
> /Users/me/Downloads/MyImage.dmg: accepted
> source=Developer ID

When we launch Chrome from our current unsigned .dmg, and that .dmg is quarantined as it would be after being downloaded, the “AppTranslocation” feature makes a copy of it in a temporary location such as /private/var/folders/3s/xql_4vks31j7vkvmwfv71j0m0000gn/T/AppTranslocation/C2B4F9E7-3590-4369-861B-908C88E72D3B/d/Google Chrome.app and runs that copy.

We don’t ever need to reach outside of Chrome’s .app bundle when we’re running, so this isn’t a major problem, but it does prevent install-from-dmg from detecting that Chrome is running from a .dmg (since it’s not). There’s also a concern that during a Keystone update, .keystone_install might not be able to find the resources it needs (either the .app bundle or the diff update tools and data) relative to itself, although I don’t believe that this actually will be a problem, because Keystone launches .keystone_install more directly, bypassing Launch Services and anything else that might invoke Gatekeeper. “AppTranslocation” appears to be tied directly to Gatekeeper. AppTranslocation is not a factor for an un-quarantined unsigned .dmg. Regardless, if Apple has made a provision to sign .dmg files, we do want to take advantage of it.

Formerly, .dmg signing was handled the same as other generic (non-Mach-O, non-installer-pkg) files: the signature was placed in a set of com.apple.cs.* extended attributes. These attributes would rarely survive a network transfer, including browser downloads over http[s]. Now (since 10.11.5, according to the tech note), when signing a .dmg, codesign places the signature in the .dmg file’s data. The “koly” trailer block is updated to point to the signature data, which codesign placed immediately preceding the “koly” trailer. The signature data and length are stored as big-endian uint64_ts at byte offsets 296 and 312, respectively. This is in the middle of UDIFResourceFile::reserved1 at https://chromium.googlesource.com/chromium/src/+/c0e39d57d0c16684ff7c99632fba9a49d4d2431e/chrome/utility/safe_browsing/mac/udif.cc#50. At that offset in the .dmg, you’ll find CSMAGIC_EMBEDDED_SIGNATURE (0xfade0cc0) and the same sort of data you’d find pointed to by an LC_CODE_SIGNATURE in a Mach-O file.

I am providing a .dmg of the current stable version of Chrome (51.0.2704.84), signed in 10.11.5, for experimentation. https://drive.google.com/a/google.com/file/d/0BzTTt3jwCXwLNUwtYllHNEU5RUk (SHA-1 c5671024ab29bdc9a1d8c8234aeb9a71209d806a). Sorry, Googlers only. I did a quick test to make sure that it works on 10.9.5, and I verified that when using it on the 10.12 preview, Chrome is able to run from the .dmg without first being copied to an AppTranslocation folder. This allows the install-from-dmg code to detect that Chrome is in fact running from a .dmg and offer to install it.

On 10.12:

$ spctl --assess --type open --context context:primary-signature -vv GoogleChrome-51.0.2704.84.signed.dmg 
GoogleChrome-51.0.2704.84.signed.dmg: accepted
source=Developer ID
origin=Developer ID Application: Google Inc.

Note that although codesign can sign and interpret these signatures on 10.11.5, spctl and Gatekeeper doesn’t understand them at all until 10.12.

Anyway, it appears that as long as we’re running the signing jobs on 10.11.5 (as we should be), fixing this will be a simple matter of running codesign on each .dmg as it’s created.