fixes #15774.
Adds runtime hardening (which is necessary for macOS app notarization) https://developer.apple.com/documentation/security/hardened_runtime
Notarization doc: https://developer.apple.com/documentation/xcode/notarizing_macos_software_before_distribution
Hardened Runtime doc: https://developer.apple.com/documentation/security/hardened_runtime
App Notarization has been tested here and here
Additional release process notes are included.
Needs backport.
22@@ -23,7 +23,7 @@ fi
23 rm -rf ${TEMPDIR} ${TEMPLIST}
24 mkdir -p ${TEMPDIR}
25
26-${CODESIGN} -f --file-list ${TEMPLIST} "$@" "${BUNDLE}"
27+${CODESIGN} --options runtime -f --file-list ${TEMPLIST} "$@" "${BUNDLE}"
After reading through the docs it seems that passing --timestamp here would also be required for notarization; given that we are signing manually?
Include a secure timestamp with your code-signing signature. (The Xcode distribution workflow includes a secure timestamp by default. For custom workflows, include the –timestamp option when running the codesign tool.)
Is there any reason why we can’t pass --strict to codesign here as well?
0 --strict options
1 When validating code, apply additional restrictions beyond the defaults.
2
3 symlinks Check that symbolic links inside the code bundle point to sealed files inside its bundle.
4 This means that broken symbolic links are rejected, as are links to places outside the bundle
5 and to places that are not, for whatever reason, sealed by the signature.
6
7 sideband Check that no resource forks, Finder attributes, or similar sideband data is present in the
8 signed code. This is now automatically enforced by signing operations.
9 Options can be specified as a comma-separated list. Use plain --strict or --strict=all to be as strict
10 as possible. Note that --strict=all may include more checking types over time.
11 Not all strictness check make sense in all circumstances, which is why these behaviors are not the
12 defualt.
Concept ACK
Can you combine #18131 into this PR. I think it makes more sense to merge them together.
I still like the idea of explicitly passing our entitlements to codesign, i.e --entitlements entitlements.xml using the file in #18171. That would also serve as some sort of documentation for what the defaults are, particularly for non-macOS users. However I’ll close that PR for now and we can discuss here.
Runtime hardening is necessary for app notarization
https://developer.apple.com/documentation/security/hardened_runtime
I added the --timestamp option.
Made a manual test run. Could successfully notarize the dmg (see log below).
I manually signed the newest nighly build https://bitcoin.jonasschnelli.ch/gitian/builds/22 by modifying the gitian-osx-signer.yml. All modified files are in the folder manual_notarization_test.
@fanquake: Adding the -entitlements now makes little sense IMO since it would be unused (it would just contain the default values). We can always add it later.
0 Date: 2020-02-21 14:11:11 +0000
1 Hash: 2462d19115966e6fc6e4c7afd264e9ec389dfbcde6cb34d0b9b5ba6524d75cd4
2 LogFileURL: https://osxapps-ssl.itunes.apple.com/itunes-assets/Enigma123/v4/84/d5/ee/84d5ee0f-e41e-29bf-4437-a3472e64a696/developer_log.json?accessKey=1582488795_6966001537870455962_Wr%2FztxOgDaSMx2v8B38P0D5i0tZW72CPjeDQ6dBVcqHi0V%2F%2BH%2FJSPK%2BC%2FHbaR7bRDf4GL4TDt1tIPMmhG6PgL4F5ehG6j80nF3HnzuHL%2FKGNALfbpotahmDjtLXsq1JVG4pSYbYgx1MO0TNnyu5dVEumhjSvwM2XyTVI%2B5qz6rU%3D
3 RequestUUID: b4e6478d-7656-404e-9de2-411b153fe184
4 Status: success
5 Status Code: 0
6Status Message: Package Approved
263+
264+```bash
265+xcrun altool --notarize-app --primary-bundle-id "org.bitcoinfoundation.Bitcoin-Qt" -u "<code-signer-apple-developer-account-username>" -p "<password>" --file bitcoin-${VERSION}-osx.dmg
266+```
267+
268+The notarizaion takes a few minutes. Check the status:
notarization
Could successfully notarize the dmg
To clarify; even though we upload the .dmg for notarization, we are only notarizing the .app bundle right?
0codesign --verify bitcoin-osx-signed.dmg -v
1bitcoin-osx-signed.dmg: code object is not signed at all
For the .app bundle (after mounting the .dmg), I’m seeing:
0codesign --verify --strict=all /Volumes/Bitcoin-Core/Bitcoin-Qt.app -v
1/Volumes/Bitcoin-Core/Bitcoin-Qt.app: valid on disk
2/Volumes/Bitcoin-Core/Bitcoin-Qt.app: satisfies its Designated Requirement
0codesign --display /Volumes/Bitcoin-Core/Bitcoin-Qt.app -v
1Executable=/Volumes/Bitcoin-Core/Bitcoin-Qt.app/Contents/MacOS/Bitcoin-Qt
2Identifier=org.bitcoinfoundation.Bitcoin-Qt
3Format=app bundle with Mach-O thin (x86_64)
4CodeDirectory v=20500 size=195212 flags=0x10000(runtime) hashes=6093+3 location=embedded
5Signature size=8973
6Timestamp=21 Feb 2020 at 10:01:11 pm
7Info.plist entries=17
8TeamIdentifier=YZC7WH3MRU
9Runtime Version=10.14.0
10Sealed Resources version=2 rules=13 files=12
11Internal requirements count=1 size=192
You can notarize an existing disk image, installer package, or ZIP archive containing your app. I think that has to do with the fact that an .app bundle is actually a folder (probably not ideal for hashing).
I tested the process described in the PRs release-notes documentation: https://bitcoin.jonasschnelli.ch/gitian/build/27 https://bitcoin.jonasschnelli.ch/gitian/builds/27/manual_notarization_plus_stapling/
One can verify the code signature by codesign -v --strict Bitcoin-Qt.app and the notarization stapling xcrun stapler validate Bitcoin-Qt.app.
ACK b513774304cc9d8f77d578cc62607f7733d76424. I’m able to verify the code signature and the notarisation of the example build @jonasschnelli uploaded.
I’ll keep an eye on it during upcoming gitian releases.
The stapled signature alleviates my privacy concerns, for now.
In the release process, I guess this needs to be appended:
Only once the Windows/macOS builds each have 3 matching signatures may they be signed (and notarised) with their respective release keys. If a notarized macOS build is never released, it will still be accepted by GateKeeper. If this is particularly dangerous Apple could be contacted to revoke it.
Some useful background on what happens if a certificate is revoked. TL&DR previously stapled builds won’t be affected, thanks to the --timestamp: https://lapcatsoftware.com/articles/notarization.html
Regarding revocation of individual tickets, Apple docs are vague:
If you discover unauthorized versions of your software, you can work with Apple to revoke the tickets associated with those versions.
I wonder what happens if Apple spontaneously decides, or is ordered to, revoke a notarisation ticket.
Would users just see the same screen as they would if we don’t staple at all? Or is there a special very scary screen? I can’t find any reports of this happening in the wild. It also begs the question how macOS goes about checking if an attached staple has been revoked. It’s not clear if this gives them any more power to prevent apps from being installed, compared to when they’re not notarised.
This stuff is surprisingly (?) poorly documented given the privacy and user autonomy implications. We should keep an eye on what happens in the wild with other apps, so we can reconsider our notarisation policy for future releases if needed.
232+ #checkout the appropriate branch for this release series
233 rm -rf *
234 tar xf signature-osx.tar.gz
235 tar xf signature-win.tar.gz
236+ #copy the notarization ticket
237+ cp dist/Bitcoin-Qt.app/Contents/CodeResoucres osx/dist/Bitcoin-Qt.app/Contents/
215+
216+ xcrun altool --notarization-info <RequestUUID-from-notarize-app-step> -u "<code-signer-apple-developer-account-username>" -p "<password>"
217+
218+Staple the notarization ticket onto the application
219+
220+ xcrun stapler staple dist/Bitcoin-Qt.app
gitian-osx-signer.yml do this, so we have gitian signatures on the final DMG?
I don’t think so since stapler is an macOS developer tool. Unsure if this can be made portable.
But, we have gitian signatures on the final dmg. Everything remains deterministic. It’s just the code signature and the notarization ticket that needs to be made manual and centralised. Though the notarization ticket is bound to the hash of the dmg (which is built deterministic).
I think t is pointless for the macOS code signing key holder to notarize something else because the .dmg hash would not match and the notarization check would fail.
We do.
The staple command above does create the CodeResources file (that actually contains the notarization ticket). The macOS code signer commits that file together with the code signatures. See this example: https://github.com/jonasschnelli/bitcoin-detached-sigs/tree/0.19/osx/dist/Bitcoin-Qt.app/Contents.
The detached-sig-apply.sh takes also that CodeResource file and places it in the final deterministic created app-folder that end up in the final dmg.
CodeResources files, that might be worth documenting. There’s one in Bitcoin-Qt.app/Contents/ that you copy below, that’s new. And then there’s one in _CodeSignature, which is bigger.
11@@ -12,6 +12,7 @@ remotes:
12 "dir": "signature"
13 files:
14 - "bitcoin-osx-unsigned.tar.gz"
15+- "signature-osx.tar.gz"
sha256sum: signature-osx.tar.gz: No such file or directory).
@luke-jr e.a. when you extract a DMG file it creates a virtual disk volume with a couple of files that aid installation:
Typically the user drags the Bitcoin Core.app file to the Applications symlink in order to install.
It’s that .app file that we staple not the dmg archive. That’s all Gate Keeper cares about, because it checks when you launch the application, not during download or installation. This has the nice benefit that we get to keep the DMG deterministic.
To preserve user privacy against Apple’s servers, I suggest that we don’t notarise the v0.19.1 release
I guess users with default security settings will also face a online check even if it is not notarized? Since the notarization process does not change the binary/installer.
Someone should really do some test in a VM when and under what settings it checks against the gatekeeper servers. Maybe I’ll find time for that soon.
I guess users with default security settings will also face a online check even if it is not notarized? Since the notarization process does not change the binary/installer.
That’s a good point. Maybe if it detects lack of runtime hardening it doesn’t ping the server.
Someone should really do some test in a VM when and under what settings it checks against the gatekeeper servers.
This would be great. If it makes no difference then we might as well notarize it.
I just wiresharked a fresh install macOS 10.15 VM where I downloaded the notarized and stapled test build https://bitcoin.jonasschnelli.ch/gitian/builds/27/manual_notarization_plus_stapling/.
It looks like even with stapling, there is a OSCP request going on.
In contrast, a “right-click open” will not cause any TCP traffic.
As for privacy (against apple), the “right-click-open” method seems to be the preferred one. Notarizing probably worsens the privacy for Bitcoin Core users.
My guess is that they’re checking to see if a previously notarized piece of software has been flagged as malware since. Which begs the question what the point of stapling is, just enabling offline installs?
I tend to agree we should stick to “right-click-open” for the time being. But let’s leave the PR open.
It looks like even with stapling, there is a OSCP request going on.
Thanks for digging into this!
🐙 This pull request conflicts with the target branch and needs rebase.
Labels
macOS
Needs rebase
Milestone
Future
