Apache Netbeans 18 is damaged and can't be opened Ventura 13.4 intel

[datb-com]

Apache NetBeans version

Apache NetBeans 18

What happened

Installing Apache Netbeans 18 from the dmg. Installed fine on two mac M1 systems, but got a signing error, from the same dmg, on two mac Intel systems. All running mac os Ventura 13.4.

How to reproduce

Presumably get the Netbean 18 dmg: Apache-NetBeans-18-bin-macosx.dmg
My experience over 4 macs indicates that this might be an Intel vs M1 issue, so use an Intel mac for this test.
Check the shasum 512 hash:
shasum -a 512 Apache-NetBeans-18-bin-macosx.dmg
45ae189936973612cdaefca127f7664257081a3794c84c28213d395f5e3cf46910bafb6f1d89a0e2466c5dc35481a9acde1be4506cf55ff356a0404052529cdd Apache-NetBeans-18-bin-macosx.dmg

Run the installer (works fine).
Run the resulting 'Apache NetBeans 18.app'

Get the error about it being damaged.

Did this work correctly in an earlier version?

No / Don't know

Operating System

mac os Ventura 13.4

JDK

ava version "17.0.5" 2022-10-18 LTS Java(TM) SE Runtime Environment (build 17.0.5+9-LTS-191) Java HotSpot(TM) 64-Bit Server VM (build 17.0.5+9-LTS-191, mixed mode, sharing)

Apache NetBeans packaging

Apache NetBeans provided installer

Anything else

Repeatable.

Are you willing to submit a pull request?

No

[neilcsmith-net]

Could you check if the community installer at https://www.codelerity.com/netbeans/ has the same issue. That's built and signed using NBPackage, which we might also consider for the non-JDK bundling installer in NetBeans 19.

[uurazzle]

Hi:

I don't believe this is an issue with distribution via .dmg. A .dmg file is a disk image file format commonly associated with macOS and don't see issues with other applications distributed using a disk image file, but probably an error during signing or software update process.

For reference, see the following Apple Developer documentation:

https://developer.apple.com/documentation/security/notarizing_macos_software_before_distribution/resolving_common_notarization_issues

codesign -vvv --deep --strict /path/to/Apache\ NetBeans\ 18.app
/path/to/Apache NetBeans 18.app: a sealed resource is missing or invalid

Or using GUI tool, Apparency

The application or component appears to have been corrupted or tampered with since being signed. As such, the identity implied by the signing certificate is not reliable. This could be a result of the application being compromised at the point of download. Or it could simply be the result of errors occurring during signing, or in a software update process — the latter is depressingly common, even and especially for built-in macOS apps.

[neilcsmith-net]

@uurazzle please can you check the community installer as mentioned in my previous comment? It will help differentiate possible causes of this problem. Thanks!

[uurazzle]

Hi @neilcsmith-net,

Ok, I downloaded the "Apache-NetBeans-18.pkg" installer package.

And it appears it doesn't have the same signing issues as the distributed disk image.

For example...

codesign -vvv --deep --strict /Applications/Apache\ NetBeans.app 
/Applications/Apache NetBeans.app: valid on disk
/Applications/Apache NetBeans.app: satisfies its Designated Requirement

For example, with the GUI tool, Apparency

I also appreciate you don't rename the application bundle with each version release with the installer packages:

"NetBeans" vs "Apache NetBeans 18", etc. Or keep it generic like "Apache NetBeans" and include the version information in the "Info.plist" file in the application bundle with the "CFBundleVersion" & "CFBundleShortVersionString" keys vs the application bundle name.

Why? It makes managing "Apache NetBeans" across a fleet of Macs much more difficult as you have to add options to specifically remove the previous version "Apache NetBeans 17" when upgrading to "Apache NetBeans 18", etc.

If the application bundle remained constant you can create your own package installer and it simply updates the previous version since the name/path is the same vs having to add additional scripting/workflow to remove the previous version name.

Let me know if you need me to test anything else.

[neilcsmith-net]

Thanks @uurazzle - that's good to know. I also downloaded Apparency and verified the two on my M1 test machine.

The NBPackage app bundle task and the scripts in the main repository have a different approach to finding libraries (inc. those bundled in JARs) to sign. NBPackage also uses the hardened runtime.

https://github.com/apache/netbeans-nbpackage/blob/master/src/main/java/org/apache/netbeans/nbpackage/macos/MacOS.java
https://github.com/apache/netbeans-nbpackage/blob/master/src/main/java/org/apache/netbeans/nbpackage/macos/AppBundleTask.java

vs

https://github.com/apache/netbeans/blob/master/nbbuild/installer/mac/newbuild/commonfiles/signNativeBinaries.sh

I wondered if something had changed in the list of files, particularly if something just on x86_64, but that doesn't seem to be the case as far as I can tell. Anyway, Apache NetBeans 17 also reports the same issue after installation.

It's curious that everything is passing notarization anyway. Another potential issue in the ASF installer is the populate_caches script -

https://github.com/apache/netbeans/blob/master/nbbuild/installer/mac/newbuild/commonfiles/postinstall/populate_caches.sh

This seems to be trying to launch from the wrong location, and then writing to a file called exiting in the root of the app. That might be breaking the signature?

If the application bundle remained constant you can create your own package installer and it simply updates the previous version since the name/path is the same vs having to add additional scripting/workflow to remove the previous version name.

Yes, all the Codelerity installers are set to do in-place upgrades. It seems the more sensible option now we're releasing every 3 months.

Let me know if you need me to test anything else.

Thanks! I'm going to check about using NBPackage to build a macOS bundle without JDK, and some testing of that would be useful. If that works, this is another reason to consider using that for NetBeans 19.

[uurazzle]

Hi @neilcsmith-net,

Ok, sounds good. Let me know if you want me to test anything when its ready.

[uurazzle]

Hi @neilcsmith-net:

One other question, there appear two builds "Intel" and "Apple Silicon", but it appears that the "Apple Silicon" is a "Universal" build and can run on either architecture (i.e. "Intel" or "Apple Silicon").

If the build really is "Universal" then I would recommend changing the naming to "Universal" vs" Apple Silicon".

Then in environments with both system architectures, could just distribute that version to simplify management by only distributing one installer package vs two.

[neilcsmith-net]

@uurazzle in which installer? The community installer is currently limited to "Intel" because of the bundled JDK. Actually, NBPackage needs to be updated to also support aarch64. But we'll need different behaviour depending on whether there is a bundled JDK, and what architecture it is. I'm not sure if there's a source of universal JDK?

[uurazzle]

Hi @neilcsmith-net:

Sorry, you are correct this disk image is intel only. Nevermind, but would be nice to have it universal.

https://www.apache.org/dyn/closer.cgi/netbeans/netbeans-installers/18/Apache-NetBeans-18-bin-macosx.dmg

[geertjanw]

Works for me in this context:

Product Version: Apache NetBeans IDE 18
Java: 20.0.1; OpenJDK 64-Bit Server VM 20.0.1+9
Runtime: OpenJDK Runtime Environment 20.0.1+9
System: Mac OS X version 13.4 running on x86_64; UTF-8; en_NL (nb)

[neilcsmith-net]

@uurazzle just tried using NBPackage to build an installer without JDK - see https://github.com/codelerity/netbeans-installers/releases/tag/v18-test1

It's under a different app bundle ID for testing, and signed and notarized with Codelerity certificate still. This might be a possibility for Apache installers for NB19 if it works better.

NBPackage needs an update to use universal architecture for the Swift launcher when there is no runtime, which I can take a look at if this seems a good way forward.

[datb-com]

Well this is very odd. It works for me now too.
Everything the same as before, except now on macOS Ventura 13.4.1 (was 13.4)
One thing I didn't try was turn-it-off-and-on-again, the 13.4 -> 13.4.1 update will have achieved that.
I have yet to retry it on the other machine where it wasn't working as that person is on holiday.

[uurazzle]

Hi @datb-com:

Once you do the workaround for the damaged application (FInder -> CTRL+click select open) I believe it adds it to the privacy database on macOS.

You can try using the tccutil command to reset the database to get the prompt again for testing purposes.

tccutil reset All <app.identifier>

Or a "big hammer" method you could delete the following file in your test user space:

rm ~/Library/Preferences/com.apple.security.KCN.plist

I haven't had time to test this myself, but an idea.

[datb-com]

Update! My colleage (on an M1) just had the same issue.
The problem is I think when we copy the downloaded .dmg to Box, and then download it from Box it ends up presumably with different hidden flags.
The file downloaded from Box still passes the shasum check, so the actual file is not altered. Presumably macOS applies some flags to the .app that gets installed from the .dmg ?

[neilcsmith-net]

@datb-com could you also see if the installer linked in my previous comment fixes that issue for you?

[uurazzle]

How about using the installer vs DMG?

IMHO, the issue is the application signature as part of the backend application build process used to create the disk images NOT modifications of the disk images. I manage a ton of applications distributed via disk images and haven't seen this type of application signature due issue to using disk images vs other methods like installer package, etc.

I would suggest downloading and trying using the GUI tool, Apparency, and reading the documentation for a better understanding of the issue.

[neilcsmith-net]

I'm taking a look at updating NBPackage to build the Swift launcher with the architecture of the bundled JDK, and universal architecture if there is none.

I've updated the previously linked download - https://github.com/codelerity/netbeans-installers/releases/tag/v18-test1 There is both a universal without JDK installer, and an installer with arm64 JDK.

It doesn't look like anyone downloaded the previous one, and there's been no feedback. The ASF installer for NetBeans 19 will not have this issue fixed unless we get some feedback on whether the universal installer option works OK and is addressing the problem!

[datb-com]

Apache-NetBeans-18-universal.pkg
This worked on an M1 mac in which the published DMG didn't work. And, my theory about it relating to having uploaded/downloaded the DMG to Box is proved incorrect.

[neilcsmith-net]

@datb-com thanks for the feedback. I've started a thread on dev@ list about this too.

[neilcsmith-net]

I've just uploaded an ASF signed package of 19-rc4 to https://nightlies.apache.org/netbeans/candidate/installers/ Please help verify this before we move to this packaging for the NetBeans 19 release. Thanks!

[neilcsmith-net]

This is hopefully resolved in NetBeans 19. Please comment here if you see the problem again.

[michaelajr]

So what is the best way to install NetBeans 19 on Apple Silicon? I tried the community x86_64 installer - and white it does work on Apple silicon - NetBeans seems slow to start up (load modules) and initialize projects compared to the Binaries (Platform Independent) zip. Does that seem right, or am I just imagining it?

[michaelajr]

Ah nvm... the .pkg installer seems to work fine.