Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
2 tasks done
Tracked by #2357
hoffie opened this issue Aug 20, 2022 · 21 comments · Fixed by #2808
Closed
2 tasks done
Tracked by #2357

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

hoffie opened this issue Aug 20, 2022 · 21 comments · Fixed by #2808
Labels
feature request Feature request
Milestone

Comments

@hoffie
Copy link
Member

hoffie commented Aug 20, 2022

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

@hoffie hoffie added the feature request Feature request label Aug 20, 2022
@hoffie hoffie added this to the Release 3.10.0 milestone Aug 20, 2022
@ann0see
Copy link
Member

ann0see commented Aug 22, 2022

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

@pljones
Copy link
Collaborator

pljones commented Aug 23, 2022

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

@ann0see
Copy link
Member

ann0see commented Aug 23, 2022

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

@hoffie
Copy link
Member Author

hoffie commented Aug 23, 2022

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
Copy link
Contributor

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
Copy link
Member

ann0see commented Aug 23, 2022

@ann0see
Copy link
Member

ann0see commented Aug 23, 2022

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
Copy link
Member

ann0see commented Aug 23, 2022

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
Copy link
Member Author

hoffie commented Aug 23, 2022

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

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

@ann0see
Copy link
Member

ann0see commented Aug 23, 2022

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
Copy link
Member Author

hoffie commented Aug 23, 2022

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
Copy link
Member

ann0see commented Aug 23, 2022

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

@emlynmac
Copy link
Contributor

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

@ann0see
Copy link
Member

ann0see commented Aug 24, 2022

@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
Copy link
Member

ann0see commented Aug 24, 2022

Ok. I think I now know what went wrong.

@ann0see
Copy link
Member

ann0see commented Aug 24, 2022

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
Copy link
Member Author

hoffie commented Aug 24, 2022

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

@ann0see
Copy link
Member

ann0see commented Aug 24, 2022

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

@hoffie
Copy link
Member Author

hoffie commented Aug 24, 2022

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
Copy link
Member Author

hoffie commented Aug 24, 2022

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 added a commit to hoffie/jamulus that referenced this issue Aug 25, 2022
…able

Previously, only (pre-)release builds were signed. This signing and
notarization was only possible with a proper developer certificate. As
the Jamulus project currently does not have one and has to rely on other
developers doing the signing, we only go this route for (pre-)releases
due to the manual effort required.
With Mac M1 support, having a valid signature becomes more important as
unsigned binaries can only be started after turning several knobs.

This commit adds very basic ad-hoc signing which does not require any
Apple account/certificate, but improves user experience for M1 users.

Fixes: jamulussoftware#2791
@hoffie
Copy link
Member Author

hoffie commented Aug 25, 2022

Feedback was positive: #2790 (comment)

hoffie added a commit to hoffie/jamulus that referenced this issue Aug 28, 2022
…able

Previously, only (pre-)release builds were signed. This signing and
notarization was only possible with a proper developer certificate. As
the Jamulus project currently does not have one and has to rely on other
developers doing the signing, we only go this route for (pre-)releases
due to the manual effort required.
With Mac M1 support, having a valid signature becomes more important as
unsigned binaries can only be started after turning several knobs.

This commit adds very basic ad-hoc signing which does not require any
Apple account/certificate, but improves user experience for M1 users.

Fixes: jamulussoftware#2791
hoffie added a commit to hoffie/jamulus that referenced this issue Aug 28, 2022
…able

Previously, only (pre-)release builds were signed. This signing and
notarization was only possible with a proper developer certificate. As
the Jamulus project currently does not have one and has to rely on other
developers doing the signing, we only go this route for (pre-)releases
due to the manual effort required.
With Mac M1 support, having a valid signature becomes more important as
unsigned binaries can only be started after turning several knobs.

This commit adds very basic ad-hoc signing which does not require any
Apple account/certificate, but improves user experience for M1 users.

Fixes: jamulussoftware#2791
hoffie added a commit to hoffie/jamulus that referenced this issue Aug 28, 2022
…able

Previously, only (pre-)release builds were signed. This signing and
notarization was only possible with a proper developer certificate. As
the Jamulus project currently does not have one and has to rely on other
developers doing the signing, we only go this route for (pre-)releases
due to the manual effort required.
With Mac M1 support, having a valid signature becomes more important as
unsigned binaries can only be started after turning several knobs.

This commit adds very basic ad-hoc signing which does not require any
Apple account/certificate, but improves user experience for M1 users.

Fixes: jamulussoftware#2791
@pljones pljones modified the milestones: Release 3.10.0, Release 3.9.1 Aug 29, 2022
ann0see pushed a commit to ann0see/jamulus that referenced this issue Nov 9, 2022
…able

Previously, only (pre-)release builds were signed. This signing and
notarization was only possible with a proper developer certificate. As
the Jamulus project currently does not have one and has to rely on other
developers doing the signing, we only go this route for (pre-)releases
due to the manual effort required.
With Mac M1 support, having a valid signature becomes more important as
unsigned binaries can only be started after turning several knobs.

This commit adds very basic ad-hoc signing which does not require any
Apple account/certificate, but improves user experience for M1 users.

Fixes: jamulussoftware#2791
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request Feature request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants