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

Remove the --no-sign option and warn the user about --adhoc-sign on macOS applications #865

Closed
freakboy3742 opened this issue Sep 24, 2022 · 4 comments · Fixed by #1214
Closed
Labels
android The issue relates to Android mobile support. enhancement New features, or improvements to existing features. good first issue Is this your first time contributing? This could be a good place to start! macOS The issue relates to Apple macOS support.

Comments

@freakboy3742
Copy link
Member

The package command provides --no-sign and --adhoc-sign options.

This is only used on macOS. Previously, macOS allowed completely unsigned apps and DMGs. However, as of macOS 12 (Monterey), apps must be signed to be able to run at all; and adhoc-signed apps won't be usable on any computer other than the one that created the app. Adhoc signing is useful for local testing, but completely unsigned apps are no longer possible on macOS.

Describe the solution you'd like

The --no-sign option should be removed. AdHoc signing should become the default signing option for all packaging on all platforms. This should be interpreted as "perform the minimal signing necessary to allow this app to run" - on Windows and Linux, this means "no signing".

Using the --adhoc-sign option on macOS should prominently warn the user that the app will work, but will not be re-distributable.

Describe alternatives you've considered

We could retain the --no-sign option and make it raise an error; however, that's not a great user experience. As macOS is the only platform that performs signing at present, it makes sense to repurpose "adhoc" signing as "do the minimum legal signing".

@freakboy3742 freakboy3742 added enhancement New features, or improvements to existing features. up-for-grabs good first issue Is this your first time contributing? This could be a good place to start! macOS The issue relates to Apple macOS support. labels Sep 24, 2022
@mhsmith
Copy link
Member

mhsmith commented Sep 24, 2022

macOS is the only platform that performs signing at present

Signing support should also be added for Android. This isn't necessary for running an app, because Gradle will just sign it with an auto-generated key which is different for each build machine. But for releasing on Google Play, you need to settle on one key and then use it consistently.

How about replacing --no-sign, --adhoc-sign and --identity with a single --sign option?

  • When --sign is not provided, Briefcase will "perform the minimal signing necessary to allow this app to run".
  • When --sign is provided, it takes one argument which is interpreted in a platform-specific way. On macOS this is "either the 40-digit hex checksum, or the full name of the identity". On Android, this would be the path to the keystore file.

@mhsmith mhsmith added the android The issue relates to Android mobile support. label Sep 24, 2022
@freakboy3742
Copy link
Member Author

Completely agreed that we need to expand signing support onto all other platforms. There's analogous support needed on iOS (which will be a pre-requisite for #860); Windows and Linux both have signing conventions as well.

I think the UX cleanup you've suggested makes sense as well. "adhoc" signing is very macOS-loaded language; "minimal viable signing" is something every platform can support (with warnings if necessary if the resulting binary won't be redistributable); and having a single option would map to the end-user's understanding of something that is being done to the build/packaging step.

The only question/alternative I'd offer is whether to add a new --sign or use the existing --identity to drive this functionality. To my reading, --sign semi-implies that signing is optional - if you don't use the option, the app won't be signed. This won't be true on macOS, or on any signing-required platform (such as Android or iOS for app release). --identity implies that signing will be performed as required by a platform, but the identity that will be used is configurable (with adhoc/fallback identities being used by default). As an added bonus, the --identity option already exists, so the migration path is a little cleaner (we only need to make --adhoc-sign and --no-sign no-ops).

@mhsmith
Copy link
Member

mhsmith commented Sep 27, 2022

Yes, that all sounds reasonable.

@basepi
Copy link
Contributor

basepi commented Apr 24, 2023

I'm looking into this during the sprint.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
android The issue relates to Android mobile support. enhancement New features, or improvements to existing features. good first issue Is this your first time contributing? This could be a good place to start! macOS The issue relates to Apple macOS support.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants