TiddlyDesktop.app is damaged and can't be opened. You should move it to the trash.

[mpmanti]

I downloaded TiddlyDesktop-macapplesilicon-v0.0.20.zip to my M1 Max macBook Pro running macOS 14.3.1, unzipped it, and moved TiddlyDesktop.app to the Applications folder. macOS refuses to open TiddlyDesktop.app.

[rmunn]

I'd guess this is probably caused by the code not being signed. The package.sh script has code that calls codesign, and I would assume that this works on @Jermolene's computer where the code signing keys live. But now that the app is being built in GitHub Actions, the codesign step is probably failing because the code signing keys aren't available. @Jermolene - You might need to add your codesigning keys as a repo secret (which should be doable from https://github.com/TiddlyWiki/TiddlyDesktop/settings/secrets/actions though since I don't have access rights to the TiddlyDesktop repo, I can't confirm that that's the correct link). Then you'd need to use that repo secret as an input to the GitHub Actions workflow: see https://docs.github.com/en/actions/security-guides/using-secrets-in-github-actions for more details there.

Then the last step will be to get the secret passed into the codesign command. Sorry I won't be able to help you there, as I have no idea where codesign wants to receive the key. If it's a file, you'll want to create a workflow step that writes the file, runs codesign, then deletes the file (so it's not accidentally bundled into the .zip file created by the workflow). If it's an environment variable, that's a lot easier: there are plenty of examples in the GitHub docs of passing secrets in as env vars.

[rmunn]

Another workaround that @Jermolene might be able to do is, after a draft release has been created by the GitHub Actions workflow, run the codesigning process on his computer and replace the macapplesilicon .zip file. That's going back to a manual step so it's less than ideal, but it would at least allow creating a stopgap release until the workflow can be tweaked to include the correct codesigning key in the correct file location.

[rmunn]

@Jermolene - You might find https://github.com/toitlang/action-macos-sign-notarize and/or https://github.com/toitlang/action-macos-sign-notarize/blob/main/action.yml helpful to get codesigning set up in GitHub Actions.

[mpmanti]

Info that may help to diagnose the issue:

I was able to download and install 0.0.18. macOS required going into System Settings > Security to allow 0.0.18 to be run. macOS does not even provide the option to do this for 0.0.20. It simply reports TiddlyDesktop.app as damaged.

[Jermolene]

Thanks @rmunn. I've yet to get codesigning working, and certainly hope to do so.

But it seems there has been a regression from v0.0.18 in terms of the behaviour of the build, do we know what accounts for that?

[DBH321]

Just want to confirm the behavior that @mpmanti sees. I get exactly the same problem with v0.0.20 but v0.0.18 works once the workaround in system Settings > Security is used. (I have an M1 Mac Studio running macOS 14.3.1).

[xpucadad]

I get the delete application error with the mac silicon version v0.0.18 as well as with v0.0.20. I have tried installing v0.0.18 several times since the v0.0.18 version was released, but have not gotten the "open anyway" error, nor is there anything in the privacy & security section of system settings.

Is there a chance that an earlier attempt to install v0.0.20 may have added something to my system that wasn't properly removed when I deleted the v0.0.20 app to install v0.0.18?

Running latest version of MacOS (14.3.1 (23D60)) on an M2 MacBook Pro.

Sorry - one additional point: I seem to remember that I did get the open error with the initial installation of V0.0.18 before I tried installing v0.0.20, but after that attempts to install v0.0.18 resulted in the delete application error.

[rmunn]

Thanks @rmunn. I've yet to get codesigning working, and certainly hope to do so.

But it seems there has been a regression from v0.0.18 in terms of the behaviour of the build, do we know what accounts for that?

I would assume it's because v0.0.20 was built on GitHub, whereas v0.0.18 was built on your own Mac. And while your Mac has a copy of your private codesigning key, GitHub doesn't. So when the codesign operation runs on GitHub, it isn't actually signing anything since it doesn't have access to a valid code-signing key to sign with. I don't use a Mac so I don't know where the code-signing key is stored, but if you know where to find it, you can upload it to your GitHub repo secrets as I mentioned in #294 (comment). Then you should be able to adjust the GitHub Actions workflow to make codesigning work.

And yes, that's a codesigning error. https://www.howtogeek.com/803598/app-is-damaged-and-cant-be-opened/ mentions that app files contained in .zip files that have been downloaded from the Internet are subject to quarantine (I presume unless they're signed with a valid key, but that page doesn't say so). It's Apple's ham-handed way of forcing developers to use Apple's official app store and pay them a hefty fee for the privilege. Yes, it can also prevent the spread of some kinds of malware, but Apple's recent actions have proved that it's income, not the good of their users, that they really care about. (Search for "apple epic game store" without quotes if you want evidence of that assertion). Thing is, it's harming open-source software too.

Anyway, rant about Apple's lousy business practices aside, the solution is definitely what I laid out in #294 (comment). You need to find where the codesigning key is stored on your computer, upload it to a repo secret, then pass it into the codesign operation via whatever parameter it takes.

[Jermolene]

Hi @rmunn I've been following Apple's recent battles with interest, and agree with your assessment.

I may not be able to work on the codesigning immediately (I need to make a new developer account with Apple).

The current Apple Silicon builds appear to be useless. I might try just removing the codesigning line from the build scripts to see if that fairs any better.

[Jermolene]

Hi @rmunn I've updated my Apple developer account, and started following these steps to get the necessary certificates installed in the GitHub Actions runner for macOS:

https://docs.github.com/en/actions/deployment/deploying-xcode-applications/installing-an-apple-certificate-on-macos-runners-for-xcode-development

Note that those instructions cover installing a provisioning profile, which I don't think we need, and so I have not created a BUILD_PROVISION_PROFILE_BASE64 secret. The code we need to do the installation is in the example YAML on that page (minus the lines marked "apply provisioning profile").

I'm a bit stuck though because I'm not familiar with the new matrix stuff, and it's not clear where to put the macOS specific set up code – could you very kindly help with that?

[rmunn]

What you probably want to do is have a step in the workflow that runs only during an OS X build, e.g. if: ${{ matrix.platform == 'osx' }}. So you could do something like this (note that I wrote this example before looking at that GitHub Actions doc):

diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml
index f3c6bf7..cc90abb 100644
--- a/.github/workflows/ci.yml
+++ b/.github/workflows/ci.yml
@@ -82,6 +82,17 @@ jobs:
           NWJS_VERSION: ${{ steps.calc-version.outputs.nwjs-version }}
           PLATFORM: ${{ matrix.platform }}
           ARCH: ${{ matrix.arch }}
+      - name: "🍎 Codesigning Mac build..."
+        if: ${{ matrix.platform == 'osx' }}
+        run:
+          # Codesigning step would go here
+          # Maybe you need a file...
+          echo "$SECRET_KEY" > /some/path/to/file.txt
+          codesign --input /some/path/to/file.txt
+          # Or maybe a command-line parameter...
+          codesign --secret-value "$SECRET_KEY"
+        env:
+          SECRET_KEY: ${{ secrets.MY_CODESIGNING_KEY }}
       - name: "📦 Packaging TiddlyDesktop..."
         run: ./package.sh
         env:

[rmunn]

The short version of the matrix stuff is that you can set up parallel builds in two ways:

1. Have GitHub do it for you, or
2. Do it yourself.

What I mean by "have GitHub do it for you" is what you see in most matrix examples in GitHub Actions documentation. You'll have two or three arrays, e.g. node: [ 16, 18, 20 ] and products: [ tiddlywiki, tiddlydesktop ] and then GitHub does, essentially, a cross-product. It turns those into "tiddlywiki with Node 16", "tiddlydesktop with Node 16", "tiddlywiki with Node 18", and so on, for a total of six matrices.

Doing it yourself is what I did, where for each matrix entry, you can specify the exact values that go into it. The include: syntax I used does that. So I defined six matrix entries, with specific values for each one.

Either way, GitHub ends up creating a configuration object called matrix that you can access within the job descriptions. So you can use it to specify the runs-on parameter, for example, so that the Mac builds run on GitHub's Mac runners (which have Xcode installed), while the Windows and Linux builds run on an Ubuntu runner (which is the fastest one). Or you can access the values from the matrix config to say "run this step only when a certain matrix property has this value", so I can run the codesigning step only when matrix.platform equals osx, which will run it for both the Intel and Apple Silicon builds. (If it's only supposed to run on the Apple Silicon build, I could have made the check if: ${{ matrix.platform-for-pkg == 'macapplesilicon' }} to target that build specifically). The point is, the values that go into the matrix object are completely under your control and can be anything, and then you can use them in the job description later on.

[mooconne]

Until the code-signing issue is resolved, this workaround will allow v0.0.20 to be run. This will remove the "quarantine" attribute from the application - use at your own risk! Verified on M2, MacOS 14.3.1

sudo xattr -c /Applications/TiddlyDesktop.app

[marriotb]

Another alternative to using xattr is to install via Homebrew. I don't know what was done differently in creating the cask from which it installs, but I tried Homebrew (brew install tiddly) when I struck the "file is damaged" issue and it installed cleanly. A big thank you to whoever it is who set up the cask -- it simplified the process greatly, because I didn't even realise that I was seeing more than a transient download issue:-)
(Running on M1 hardware in Sonoma 14.5)

[jekuno]

@marriotb The Homebrew cask uses the Intel build which needs Rosetta and starts much slower than the native Apple build.

The workaround from @mooconne works on both M1 and M2.

[rawjeev]

Until the code-signing issue is resolved, this workaround will allow v0.0.20 to be run. This will remove the "quarantine" attribute from the application - use at your own risk! Verified on M2, MacOS 14.3.1

sudo xattr -c /Applications/TiddlyDesktop.app

I am facing the same problem on an M1 Mac. I tried the Intel build and the cat jumps a few times before the app opens. Which is visibly slow.

I can live with this workaround till the code-signing issue is resolved. Thank you @mooconne