Validator didn't open on MacOS

[dget]

Bug report

Describe the bug I got the error below after trying to open the validator.

How we reproduce the bug

1. Downloaded the MacOS release of 3.1.0
2. Try to open it

Screenshots: Visual examples can help us better understand the issue.

Environment versions

• validator version: 3.1.0
• Java version:
• OS versions: MacOS 10.15.7

[github-actions[bot]]

Thank you for your reporting a bug. The issue has been placed in triage, the MobilityData team will follow-up on it.

[bdferris-v2]

I've been able to repro this on my own laptop with the release image, but not with one built locally. I'm not sure what's going on, but I'll do some investigation on the Github workflow to start.

[bdferris-v2]

I've found a similar error described in https://bugs.openjdk.org/browse/JDK-8276150. Indeed, when I'm able to repro this myself: when I upload my locally built dmg (which I've verified runs successfully) to a website and download it back, the same file is now reported as damaged. I think it all boils down to a code signing issue.

Interestingly, this was considered to be an actual bug in the JDK and it seems that while they attempted a fix in 2021, it didn't take and the fix was reapplied to the JDK just 30 days ago: https://bugs.openjdk.org/browse/JDK-8277493

I'm still investigating if that fix has made it into a production JDK yet. Also evaluating if we could/should sign the app ourselves to get around some of these errors.

[bdferris-v2]

Ok, did a little more digging and here is what I've found.

Per the original JDK bug, this issue occurs when a "signed" (in the Apple code-signing sense) Java SDK is used to build a local jpackage application. The resulting application still has the original signature, but a slightly different binary, so Mac OS thinks the binary is damaged (paraphrasing a bit here).

I've been able to see this by building the app (./gradlew jpackage) and looking at the code signing details of the app:

codesign -v -d app/pkg/build/jpackage/GTFS\ Validator.app

On my Mac with the default Java 15 runtime, I see output like the following:

Executable=/Users/bdferris/IdeaProjects/gtfs-validator/app/pkg/build/jpackage/GTFS Validator.app/Contents/MacOS/GTFS Validator
Identifier=jpackageapplauncher
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20500 size=1396 flags=0x10000(runtime) hashes=35+5 location=embedded
Signature size=6132
Timestamp=Mar 29, 2022 at 8:12:30 AM
Info.plist=not bound
TeamIdentifier=not set
Runtime Version=10.15.0

That all indicates a signature is in place. When this app is downloaded from the web and run, Mac OS attempts to verify the invalid signature and fails. Thus, the "damaged" warning.

The fix PR addresses this issue by unsigning the resulting app binary using the codesign --remove-signature command. Unfortunately, the fix only made it into the hot-off-the-presses Java 18 SDK.

I've actually been able to verify the fix by installing a Java 18 SDK from the Amazon Corretto build of OpenJDK (link). The resulting binary is unsigned, with a codesign output of:

app/pkg/build/jpackage/GTFS Validator.app: code object is not signed at all

Ok, so what does an unsigned binary actually get us? The following different warning dialog when you try to run the app:

You still can't run the app! Actually, scratch that, you can, but you have to be a hacker and right click on the app icon and select Open to tell Mac OS that you really want to run this untrusted, unsigned, unloved piece of code you just downloaded off the internet.

So... that's what I know about the bug. What should we actually do? More on that in the next comment.

[bdferris-v2]

In terms of a fix, I see the following options:

1. We sign the app. This will require an Apple Developer account and some associated dev keys. Normally, those cost $99 a year, but I believe non-profits like Mobility Data could get one for free. But it would take some time to setup. I've not actually been able to try this "fix" myself, since I don't have a dev account, but the jpackage tool supports Mac OS code signing and I've found other Gradle project who are signing their Mac apps like this. I believe it should work. But I acknowledge we are starting to get out of the realm of "let's knock out a quick Java app because the alternatives are complex". The nice thing about this approach is that users wouldn't get untrusted code warnings when running our app.
2. We produce an unsigned app. This will give the "cannot open untrusted app" warning mentioned above, but as noted, it can be bypassed. Not ideal, but maybe worth pursuing in the near-term? I see two paths to achieve an unsigned app, given the JDK bug.
   • We use Java 18 when building our app in the GitHub workflow. Unfortunately, this isn't totally straightforward. Not all OpenJDK Java 18 distros appear to have the fix (Amazon Corretto yes, Azul Zulu no) and some distros aren't even building Java 18 yet (Eclipse Adoptium Temurin). What's worse, Gradle 7.4 doesn't support Java 18, so we'd have to update the project to Gradle 7.5-rc1, since 7.5 isn't technically released yet. This seems like a bit too much bleeding edge all around.
   • As an alternative, we could remove the code signature ourselves. I've seen other projects that use this approach, basically running codesign --remove-signature in their GitHub workflow and repacking the resulting binary as a dmg. That's the approach I'm taking in PR #1186 and I can confirm that it produced a binary package file that is unsigned. This maybe seems like a not-too-terrible workaround while we wait for a Developer Account for proper code signing or for Java 18.

[maximearmstrong]

After discussion with @isabelle-dr, we will proceed with option 1 as it would be the best one for users. I'm okay with option 2.2 as a quick fix while we are working on the Developer Account, if it's okay for Isabelle.

@fredericsimard Could we setup an Apple Developer Account for MobilityData please?

[fredericsimard]

@maximearmstrong I just got approval from Jessica, and we will need her as we need to provide quite a lot of information during registration, like tax numbers, bank accounts, DUNS, etc. The only unknown here time-wise is the non-profit status validation, which is an extra step I believe. So, I would estimate about a week before you can start signing apps for distribution.

And yes, the fees are waived for non-profits.

[fredericsimard]

The enrollment request has been sent to Apple, we have to wait a few days for them to check things. I will keep you informed once we are approved.

[bdferris-v2]

Ok, thanks for the updates. @maximearmstrong per your guidance, I've finalized PR #1186 and it's now ready for review. Thanks!

[fredericsimard]

Also, small note, and I don't know if Java apps are allowed, we could distribute the app through the Mac App Store and hide it from the public. Only those who have the URL can download and install it. That is a recent change. So it could be easier for updates and maintenance. Just a FYI.

[fredericsimard]

Update : The enrolment into Apple Developer Program was approved by Apple this morning, now we need to continue with it, add users, etc. Will take a few more days, but I reckon this will be all done by Friday.

[isabelle-dr]

Hello @dget, thank you for opening your first issue in this repo! If you haven't already, you can meet the community in the MobilityData slack, and join the #gtfs-validators channel for updates and questions regarding our GTFS Schedule and Real-time validators.

We have released a new release with a fix to this issue, can you try to run the validator again using v3.1.1?

Welcome to the community! 🎉

[isabelle-dr]

Closing - this has been tested.

[dget]

Thanks @isabelle-dr! I can do a new ticket for this, but I have the following issue when I try running. I can right click and open it, but my teammates also ran into it:

[bdferris-v2]

@dget this is works-as-intended for now. Until we can get the app officially signed by apple, the temporary workaround will require you to right-click to open initially.

[dget]

Thanks! Question just for my own curiosity: what's that process / how long does it usually take?

[maximearmstrong]

1. We sign the app. This will require an Apple Developer account and some associated dev keys. Normally, those cost $99 a year, but I believe non-profits like Mobility Data could get one for free. But it would take some time to setup. I've not actually been able to try this "fix" myself, since I don't have a dev account, but the jpackage tool supports Mac OS code signing and I've found other Gradle project who are signing their Mac apps like this. I believe it should work. But I acknowledge we are starting to get out of the realm of "let's knock out a quick Java app because the alternatives are complex". The nice thing about this approach is that users wouldn't get untrusted code warnings when running our app.

@bdferris-v2 We now have an Apple Developer account. I think we can move forward with option 1. Would you like to work on this? Also, @isabelle-dr what priority should this have?

[isabelle-dr]

@maximearmstrong @bdferris-v2 I would say pretty high, I received several e-mails regarding this issue. I myself can't use the validator app either 🙈

The next step would be issue #1200

[fredericsimard]

@bdferris-v2 I have access to the Developer account, let me know what kind of certificate you require. I tried contacting you via Slack for at least 2 weeks, but never got a reply.

[bdferris-v2]

I will try to put some cycles on this, but might be a week or two realistically.