Code-signing and notarisation

[Eitot]

See also #765

macOS Mojave (10.14.5 and newer) and macOS Catalina require notarisation in addition to code-signing to pass Gatekeeper. At this point, new releases of Vienna have to be notarised, otherwise users will have to manually override Gatekeeper, which can discourage them from using the app in the first place.

After looking a bit at the code-signing and release process of Vienna I believe that the process is complex (lots of different parts within large shell scripts), restrictive (seems to work only in command-line and not Xcode) and not really open for others to use (e.g. code-signing is coupled with Sparkle and the upload to repos). On top of that, the process is not yet capable of producing notarised copies, which will require some work if it is to be included in the process and not done manually afterwards.

I think simplifying the process could ensure that others are able to sign and release new versions in the future and that we could set up a process for nightly/weekly builds for people to test.

I have already simplified the build process a little bit (#1257) by merging the build targets. More can be done, such as:

• Separating the build scripts by their purpose (versioning, building, signing, uploading)
• Reducing reliance on third-party tools such as Autorevision (which could be done manually and by Apple’s own agvtool (bundled with Xcode build tools)
• Making sure that most parts work well in xcodebuild as well as Xcode and relying on Xcode’s code-signing tools

[josh64x2]

This is going to make it a lot easier to release bug fixes going forward. One thing we need to consider is which developer ID we are going to sign the app with.

[barijaona]

The main difficulty I see is that the current version of Sparkle seems unsuited with the goal of having multiple people able to deliver new versions.

In particular, EdDSA keys are personal, and apparently a developer can only have one active. I am still in search of a way to backup mine in order to transfer it to another Mac…

I am not sure I fully understand what Sparkle documentation means by :

If you both code-sign your application and include a public EdDSA key for signing your update archive, Sparkle allows issuing a new update that changes either your code signing certificate or your EdDSA keys. Note however this is a last resort and should only be done if you lose access to one of them.

[barijaona]

There is work in progress in Sparkle regarding the key portability problem, but this lacks documentation.

[Eitot]

I suppose the quote means that Sparkle will not complain if e.g. the (Apple) code-sign identity changes between versions (e.g. from yours to someone else’s) as long as the EdDSA key remains the same. Conversely, it won’t complain if the EdDSA key changes if the code-sign identity has not changed. I suspect therefore that it verifies both but won’t cancel the process if either one does not check out.

[barijaona]

It is the this is a last resort and should only be done if you lose access part which remains mysterious for me.

If developer A creates a 'Developer ID Application certificate' intended to be used solely for Vienna, and shares it with developer B and C, will any use by developer B be considered by Sparkle as a last resort situation or will it be a normal situation ?

If the later is true, I guess we would just have to specify a .csreq with this exact certificate fingerprint.

[barijaona]

Can you have a look at PR #1291 ? (feedback on Release Instructions especially needed)

As this is an open source project, I always have taken care to avoid that informations related to an individual or a developer team pollute Vienna's project.pbxproj. This is done by having code signing identity set through the CS-ID.xcconfig file, which is private and ignored by git.

Alas, for Sparkle autoupdate, I see no other solution than sharing the private key between core developers.

I recognize there are a lot of scripts involved in the release process, but it seems unavoidable considering the various things to be ensured :

• versioning,
• auto-update (with distinction of beta and release versions),
• documentation of versions,
• code signing and notarization.

Personally, I find modular scripts easier to maintain than a huge monolithic project.pbxproj file often affected by various Xcode bugs…

Next steps to be done : sandboxing (related to #262) (version 2 of Sparkle), and edDSA signature #1282.

[JanX2]

Something that might help in this process is a small addition that aids Apple platform OSS development greatly for me as it allows adding individual developer ID support:
https://github.com/JanX2/Cog/tree/oss-dev-team
https://github.com/JanX2/YoutubeDownload

It’s pretty simple to add:
JanX2/Cog@f5edb6a

If there are any questions, I will try to answer them, though I get so many notifications here that I might not see any. Please try email in that case. ;)

[barijaona]

Something that might help in this process is a small addition that aids Apple platform OSS development greatly for me as it allows adding individual developer ID support

The goal of the DEVELOPMENT_TEAM.xcconfig which is present in these projects seems to be quite similar to CS-ID.xcconfig currently used by Vienna.
Do you see a real advantage in having a Shared.xcconfig alongside ? What could land in this file ?

[JanX2]

@barijaona
I simply hadn’t seen that change. :D

In my opinion, having something like Make-ID-Template.sh, now deceased, would be useful. Especially, if it can figure out the CODE_SIGN_IDENTITYautomagically (would probably have to be run from Xcode) and create the .pem. But those are nice-to-haves…