-
Notifications
You must be signed in to change notification settings - Fork 69
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
Presence of libjnidispatch.jnilib triggers Mac notarization failure #199
Comments
Greetings @rschmunk! Yes, the It looks like Apple flipped the switch on their relaxed notarization prerequisites, and that's causing lots of headaches. I'm not sure if you ran across this stackoverflow post, but it describes what they had to do to sign native libraries bundled within a jar. |
@lesserwhirls, So if |
In that case yes, |
Hmmmmmm..... Well, I only know of the one user who might have specifically taken advantage of this feature in Panoply, so it might have to go away until NJ uses a newer JNA. Or perhaps I'll bundle a version of NJ missing JNA in the Mac version only. |
I get the feeling that the second option is what will need to be done, at least for now. The JNA developer does not seem interested in signing the Jars for Mac (or Windows, for that matter), so it looks to be falling on the individual developers utilizing JNA to sign as needed. (which invloves expanding the jar, signing, rejarring, etc.). The IDV group at Unidata does some signing, but I'm not familiar with how it works myself, and I believe they rely on Install4J to manage all of that. I'd be happy to put you in touch with one of them to see if they have any tips/tricks. |
Thx, @lesserwhirls. I'll figure something out. Simplest option for me is to just disable JNA, but as long as I can script whatever I implement I'll be satisfied. I'm an odd outlier in that I use Xcode as my IDE and ant for my build scripting. (Hey, I only started using ant maybe 7-8 years ago!) The Mac notarization process has messed that up as my process for building, signing and uploading was for several years a single ant command-line call. Now that has been replaced by two CL commands with a quick coffee break in between, assuming no notarization failure. |
I discovered an issue in the java-native-access/jna#1154 repo about problems submitting apps using Java and JNA to the Mac app store beginning late last year, which was being triggered by the JNA code for Darwin being fat (32- and 64-bit) and the app store no longer accepting any submission that included 32-bit code. One commenter on that issue showed how to strip the 32-bit code out of the Darwin JNA That said, I have no idea whether use of the |
Nice! I wonder if we could do some jar shading magic in our build once the two mac platforms are separated out, and make the new |
Has any further thought been given to producing a netcdfAll.jar that does not include the 32-bit Darwin native binary code? This is not a priority for me now, as I have set up a script that builds netcdfAll, then unjars it, strips out the offending binary, and re-jars everything back up. Nevertheless, I'm curious, and so wanted to see if it might be in the queue somewhere. Also wondering to what extent are there still Darwin boxes out there that are 32-bit only? |
It looks like jna still ships the universal binary for darwin, so we would not be able to shade out out the 32-bit specific parts on our end just yet. Once jna splits the universal binary into a 32-bit and a 64-bit version, then we'd be able to work some gradle magic. I have no idea as to the extent of 32-bit darwin systems, or the use of 32-bit java on 64-bit darwin systems (which would still require the use of a 32-bit lib). |
@lesserwhirls, I can dig it. The only negative in this is that it means I can forget about downloading a netcdfAll.jar release binary and plugging it into my app. But as the majority of my releases the past year have been using SNAPSHOTs, that's not really a problem at the moment. |
@rschmunk speaking of notarization, we are starting to look into it for the IDV. Do you, perchance, have any advice or suggestions for us as we embark on this effort? I'm speaking more broadly about the notarization of a Java client application, not specifically about this issue. Did you ever successfully notarize Panoply? Thank you. (ping @yuanho). |
@julienchastang and @yuanho, Panoply releases for macOS since IIRC late 2019 have been all been notarized, as have a couple of my other Java apps. There have been a few times, such as the case described in this issue, when I had to tweak the process because of Apple tightening the screws a little more. Aside from the occasional update, the only problem I have with notarization now is that it used to be that I could trigger a compile, build, codesign, and upload of an app in a single command. Now it's a two-command process with a 5-10 minute coffee break in between while I wait for notarization to process. (Well, three steps at the moment due to WFH and dealing with the office VPN, but two steps whenever I'm allowed back in the office.) I have a few notes on the notarization process for a Java app, mostly reminders to self rather than a detailed step-by-step menu. I could probably flesh that out. You'll note my workplace in my profile; you can e-mail me at the appropriate address. |
I am trying to finish packaging up a copy of Panoply for macOS using netCDF-Java 5.3 SNAPSHOT. Everything is great right up until almost the end when I have to get the disk image DMG notarized by Apple. That fails because of the presence of libjnidispatch.jnilib in the NJ jar, i.e., netcdfAll-5.3.0-SNAPSHOT.jar/com/sun/jna/darwin/libjnidispatch.jnilib. In short, the notarization process is complaining that the libjnidispatch.jnilib binary is not properly signed.
Note that this problem did not occur last Friday (January 31) when I was making a Mac package, but I have a dim recollection that Apple was going to be closing some loophole for notarizing Java based apps effective February 1. Or perhaps that was apps built on an an old Java, such as the Java 8 that NJ is based on.
I realize that dealing with this is pretty much outside Unidata's purview, but it's something that could completely break my ability to distribute a netCDF-Java based app to macOS users with an up-to-date operating system. But I am wondering what libjnidispatch.jnilib is used for in NJ, and whether it's really necessary?
ETA: I see that JNI is necessary in order to use the library to write NC4 files. A quick and dirty test suggests that removing the offending jnilib from the NJ jar does not cause any breakage when opening and reading datasets, but I will need to test that more throughly before relying on it.
The text was updated successfully, but these errors were encountered: