5b4c771866
## Issue being fixed or feature implemented Slightly changes the detached signature creation code ## What was done? Investigated what exactly needed to be done for notarization (docs to come), tried it again, then when it failed as expected trying to figure it out, then figuring it out :) simple change in the end. ## How Has This Been Tested? created macOS detached sigs and notarized 19.0.0-rc.10 binaries and ensured that all worked as expected. See binary attached here (sha256 3829e863831b05c3d76785540183bee556c4bab03dac98f5872df06668b9cb20) [dashcore-19.0.0-rc.10-osx.dmg.zip](https://github.com/dashpay/dash/files/11246273/dashcore-19.0.0-rc.10-osx.dmg.zip). You can also do a signed gitian-build for rc.10 and should replicate these hashes. ## Breaking Changes Should be none; I would like to backport this to 19 as a 19.0.1 ## Checklist: - [x] I have performed a self-review of my own code - [ ] I have commented my code, particularly in hard-to-understand areas - [ ] I have added or updated relevant unit/integration/functional/e2e tests - [ ] I have made corresponding changes to the documentation - [x] I have assigned this pull request to a milestone _(for repository code-owners and collaborators only)_ |
||
---|---|---|
.. | ||
background.svg | ||
custom_dsstore.py | ||
detached-sig-apply.sh | ||
detached-sig-create.sh | ||
fancy.plist | ||
gen-sdk | ||
LICENSE | ||
macdeployqtplus | ||
README.md |
MacOS Deployment
The macdeployqtplus
script should not be run manually. Instead, after building as usual:
make deploy
During the deployment process, the disk image window will pop up briefly when the fancy settings are applied. This is normal, please do not interfere, the process will unmount the DMG and cleanup before finishing.
When complete, it will have produced Dash-Qt.dmg
.
SDK Extraction
Step 1: Obtaining Xcode.app
Our current macOS SDK
(Xcode-12.1-12A7403-extracted-SDK-with-libcxx-headers.tar.gz
) can be
extracted from
Xcode_12.1.xip.
Alternatively, after logging in to your account go to 'Downloads', then 'More'
and look for Xcode_12.1
.
An Apple ID and cookies enabled for the hostname are needed to download this.
The sha256sum
of the archive should be 612443b1894b39368a596ea1607f30cbb0481ad44d5e29c75edb71a6d2cf050f
.
After Xcode version 7.x, Apple started shipping the Xcode.app
in a .xip
archive. This makes the SDK less-trivial to extract on non-macOS machines. One
approach (tested on Debian Buster) is outlined below:
# Install/clone tools needed for extracting Xcode.app
apt install cpio
git clone https://github.com/bitcoin-core/apple-sdk-tools.git
# Unpack Xcode_12.1.xip and place the resulting Xcode.app in your current
# working directory
python3 apple-sdk-tools/extract_xcode.py -f Xcode_12.1.xip | cpio -d -i
On macOS the process is more straightforward:
xip -x Xcode_12.1.xip
Step 2: Generating Xcode-12.1-12A7403-extracted-SDK-with-libcxx-headers.tar.gz
from Xcode.app
To generate Xcode-12.1-12A7403-extracted-SDK-with-libcxx-headers.tar.gz
, run
the script gen-sdk
with the path to Xcode.app
(extracted in the
previous stage) as the first argument.
# Generate a Xcode-12.1-12A7403-extracted-SDK-with-libcxx-headers.tar.gz from
# the supplied Xcode.app
./contrib/macdeploy/gen-sdk '/path/to/Xcode.app'
Deterministic macOS DMG Notes
Working macOS DMGs are created in Linux by combining a recent clang
, the Apple
binutils
(ld
, ar
, etc) and DMG authoring tools.
Apple uses clang
extensively for development and has upstreamed the necessary
functionality so that a vanilla clang can take advantage. It supports the use of -F
,
-target
, -mmacosx-version-min
, and -isysroot
, which are all necessary when
building for macOS.
Apple's version of binutils
(called cctools
) contains lots of functionality missing in the
FSF's binutils
. In addition to extra linker options for frameworks and sysroots, several
other tools are needed as well such as install_name_tool
, lipo
, and nmedit
. These
do not build under Linux, so they have been patched to do so. The work here was used as
a starting point: mingwandroid/toolchain4.
In order to build a working toolchain, the following source packages are needed from
Apple: cctools
, dyld
, and ld64
.
These tools inject timestamps by default, which produce non-deterministic binaries. The
ZERO_AR_DATE
environment variable is used to disable that.
This version of cctools
has been patched to use the current version of clang
's headers
and its libLTO.so
rather than those from llvmgcc
, as it was originally done in toolchain4
.
To complicate things further, all builds must target an Apple SDK. These SDKs are free to download, but not redistributable. To obtain it, register for an Apple Developer Account, then download Xcode_12.1.
This file is many gigabytes in size, but most (but not all) of what we need is contained only in a single directory:
Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk
See the SDK Extraction notes above for how to obtain it.
The Gitian descriptors build 2 sets of files: Linux tools, then Apple binaries which are created using these tools. The build process has been designed to avoid including the SDK's files in Gitian's outputs. All interim tarballs are fully deterministic and may be freely redistributed.
xorrisofs
is used to create the DMG.
xorrisofs
cannot compress DMGs, so afterwards, the DMG tool from the
libdmg-hfsplus
project is used to compress it. There are several bugs in this
tool and its maintainer has seemingly abandoned the project.
The DMG tool has the ability to create DMGs from scratch as well, but this functionality is
broken. Only the compression feature is currently used. Ideally, the creation could be fixed
and xorrisofs
would no longer be necessary.
Background images and other features can be added to DMG files by inserting a
.DS_Store
before creation. This is generated by the script contrib/macdeploy/custom_dsstore.py
.
As of OS X 10.9 Mavericks, using an Apple-blessed key to sign binaries is a requirement in order to satisfy the new Gatekeeper requirements. Because this private key cannot be shared, we'll have to be a bit creative in order for the build process to remain somewhat deterministic. Here's how it works:
- Builders use Gitian to create an unsigned release. This outputs an unsigned DMG which users may choose to bless and run. It also outputs an unsigned app structure in the form of a tarball, which also contains all of the tools that have been previously (deterministically) built in order to create a final DMG.
- The Apple keyholder uses this unsigned app to create a detached signature, using the script that is also included there. Detached signatures are available
- Builders feed the unsigned app + detached signature back into Gitian. It uses the pre-built tools to recombine the pieces into a deterministic DMG.