-
Notifications
You must be signed in to change notification settings - Fork 133
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
Notarization error: the staple and validate action failed! Error 65 #431
Comments
Hi @amariottini! |
Thanks @fvarrui, but I don’t understand how to follow point 2 of the proposed solution. |
Ok I think I understood: |
For anyone having the same problem, I solved signing libjnidispatch.jnilib and replacing the dynamic dependency on JNA with a static dependency on the modified (signed) jar. In In I produced jna-5.8.0-signed.jar in this way:
However I'd like to find a way to dynamically sign during build process. |
So, as far as I understood, this issue is caused by .jnilib or .dylib native libraries inside .jar files? |
If so, maybe JP could do a kind of deep code signing, looking for native libraries in dependencies? |
Exactly. |
@fvarrui is there any test version or workaround available yet? I have the exact same issue, my project uses many different 3rd Party libs with bundled native .jnilib, .dylib and .so files which are located in the jar. The notarization fails as these native libs are not signed. It seems there is no built in way to handle this correctly with the javapackager plugin yet? |
Hi @grill2010! |
@fvarrui Well signing the jars from the runtimeClasspath is actually not that hard, I just do it that way
which actually extracts the jars and signs all native libs, the only problem is that there is no way of how I can replace the
folder with my signed jars. I tried to set the copyDependencies to false and just add the libs manually via the additionalResources like that
Unfortunately the created app doesn't launch because of some Caused by: java.lang.ClassNotFoundException. I think this is because the runnable jar is created differently when setting the copyDependencies to false. There is also no hook or task I can bind my gradle script to so that I can execute a task as soon as the app was created but before the signing and dmg file creation starts. Any other ideas of how to make it work? |
Okay I actually got it working, the issue was the Manifest file which did not include the class path when setting the copyDependencies to false. I do it like that in my configuration
so in order to workaround this issue I use this
I also set a manual jre because when you set the copyDependencies to false the standard bundled jre will miss some stuff. So I built the app once with And as mentioned before I sign all my dependencies automatically via this task
I also updated the section for deleting unsupported files after realizing it was unintentionally removing contents from the META-INF directory and entire directories. This update is specific to my project, but I hope it’s useful information. If you consider adding similar functionality to javapackager, it would be incredibly helpful to have an option for excluding certain files from JARs. In my case, some third-party JARs contained files that couldn't be signed and were subsequently rejected during notarization. |
Hi @grill2010! |
I'm submitting a…
Short description of the issue/suggestion:
I didn't make a new build of my application for some months.
Now I have di error at the end of notarization process:
"The staple and validate action failed! Error 65"
Steps to reproduce the issue/enhancement:
Simply executed packageMyAppForMac task.
What is the expected behavior?
Have the app notarized
What is the current behavior?
These are the last lines of the log:
I executed this command: xcrun notarytool log 7210bde9-0c6a-4e7f-ba16-178b06659599
with this result:
Do you have outputs, screenshots, demos or samples which demonstrate the problem or enhancement?
What is the motivation / use case for changing the behavior?
Please tell us about your environment:
Other information (e.g. related issues, suggestions how to fix, links for us to have context)
The text was updated successfully, but these errors were encountered: