Mac: Sign non-release builds with self-signed key

[hoffie]

What is the current behaviour and why should it be changed?

Currently, only release builds are signed via @emlynmac. Now that we provide M1 builds (#2357), it would be interesting to sign non-release builds as well, as M1 Macs refuse to run unsigned binaries by default.

Describe possible approaches

It should be sufficient to use a self-signed key for that.

• Key generation (turned out to be unneeded)
• Build logic changes

Has this feature been discussed and generally agreed?

See #2357

[ann0see]

I can create a cert. However, should we share it internally?

[pljones]

Should it go into jamulussoftware/assets or jamulussoftware/settings/secrets/actions?

[ann0see]

Since it's a cryptographic key, it needs to go to the secrets tab, not a repo.

[hoffie]

However, should we share it internally?

I think it should be ok to store it as a secret only. It will not be easily recoverable there though (but we shouldn't need it).
In addition to the key, we also need to adjust the build logic to avoid trying the online (apple.com) parts of the signing process. I guess it makes sense to do this via another boolean secret to make that decision (or derive it from the cert if possible?).

[emlynmac]

Maybe have a look at the existing signing system and add the relevant gitHub secrets to enable signing.
It may require some further changes to make sure the notarization path is not followed, but should be simpler to do that way.

[ann0see]

I think I followed https://www.simplified.guide/macos/keychain-cert-code-signing-create once.

[ann0see]

I think I've now added everything unrelated to notarization from my side on this repo. So we'd need to skip MACOS_CERTIFICATE_ID and NOTARIZATION_PASSWORD

[ann0see]

Ok. I've now added a fake password and for the MACOS_CERTIFICATE_ID the name of the certificate, but on a workflow_dispatch run nothing changes.

[hoffie]

I think we need several more changes (which could probably be done on a fork first):

• jamulus/.github/autobuild/mac.sh

  Line 44 in e14f3dd

  [[ -n "${NOTARIZATION_PASSWORD:-}" ]] || return 1

  needs dropping, I think
• These ifs need additional checks for the NOTARIZATION_PASSWORD secret:

  jamulus/.github/workflows/autobuild.yml

  Line 387 in e14f3dd

  if: >-

  jamulus/.github/workflows/autobuild.yml

  Line 399 in e14f3dd

  if: >-

Not sure if this is everything, but I guess both of it is mandatory for it to work.

[ann0see]

Yes, that could be done.

However, I think we still need something else: https://github.com/jamulussoftware/jamulus/runs/7982936025?check_suite_focus=true#step:10:7 should have imported the cert, but it didn't.

[hoffie]

I think PRs don't have access to the target repo secrets, not sure if this changes if the PR comes from the same repo as that one did.

[ann0see]

The secret tab says there's only no access for PRs from forks

[emlynmac]

Each fork has its own secrets. For testing and developing, you'll need the values in your fork

[ann0see]

@emlynmac I just did that, but they didn't show up as "env" in GitHub actions' log. I also don't see any place where one could enable them from being read. Did you have to enable anything?

[ann0see]

Ok. I think I now know what went wrong.

[ann0see]

Actually, I think our way is not the way to go: https://wiki.lazarus.freepascal.org/macOS_Big_Sur_changes_for_developers#Code_signing_-_Intel_vs_M1

Probably we need ad hoc signing

[hoffie]

So, might codesign --force --deep -s - MyApp.app be sufficient? :o

[ann0see]

Maybe? I can't test it since I only have access to Intel based Macs

[hoffie]

I'm currently running test builds with the macdeployqt -codesign="-" logic, which should be rather equivalent to the above call.
Logs: https://github.com/hoffie/jamulus/runs/7993202492?check_suite_focus=true#step:10:7814

[hoffie]

I've linked the resulting test build and asked for testers here, as my branch was mainly about the universal builds and the codesigning would just be a positive side effect: #2790 (comment)

[hoffie]

Feedback was positive: #2790 (comment)