Skip to content

Preserve the Entitlements directory in podspec - #2062

Merged
zorgiepoo merged 1 commit into
sparkle-project:2.xfrom
digitalmoksha:digitalmoksha-podspec-preserve-entitlements
Jan 16, 2022
Merged

zorgiepoo merged 1 commit into
sparkle-project:2.xfrom
digitalmoksha:digitalmoksha-podspec-preserve-entitlements

Conversation

@digitalmoksha

@digitalmoksha digitalmoksha commented Jan 16, 2022 •

Copy link
Copy Markdown
Contributor

In order to code sign Sparkle when installing via a Pod, the Entitlements directory needs to be available.

(Insert summary of your pull request here)

Fixes #2062

Misc Checklist:

  • My change requires a documentation update on Sparkle's website repository
  • My change requires changes to generate_appcast, generate_keys, or sign_update

Only bug fixes to regressions or security fixes are being backported to the 1.x (master) branch now. If you believe your change is significant enough to backport, please also create a separate pull request against the master branch.

Testing

I tested and verified my change by using one or multiple of these methods:

  • Sparkle Test App
  • Unit Tests
  • My own app
  • Other (please specify)

(Describe all the cases that were tested)

macOS version tested: 12.1

In order to code sign Sparkle when installing via a Pod, the `Entitlements` directory needs to be available.
@zorgiepoo

zorgiepoo commented Jan 16, 2022 •

Copy link
Copy Markdown
Member

Thanks. This only affects developers that use the Downloader XPC Service and use a manual re-signing workflow (otherwise Xcode's archive/export process preserves the entitlement). Workaround is fetching the entitlements file from the repo or a distribution. (If you do use the Downloader XPC Service please file a bug to Apple about not being able to use WebKit2).

@zorgiepoo
zorgiepoo merged commit 403209b into sparkle-project:2.x Jan 16, 2022
@digitalmoksha

Copy link
Copy Markdown
Contributor Author

Thanks @zorgiepoo! Although I don't use the Downloader XPC, it do have a manual signing process. So the simplest thing at the moment is to sign it and just not enable it.

@zorgiepoo

zorgiepoo commented Jan 17, 2022 •

Copy link
Copy Markdown
Member

Ah well, if you don't use it, it doesn't really matter a whole lot how it gets signed because it will be unused. You could technically even remove it if you want.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants