JNA jar 5.6.0 being flagged by Carbon Black

[jna2021]

We recently added jna into our application and now certain users are facing issues with Carbon Black .It looks like the dll is being extracted into a certain location on/during the application launch and Carbon black doesn't like it and flags it.

How do we get around this problem? Our app is used by clients across various companies and they may not have Carbon Black but something similar on their end.

Is there a generic way to tackle this? Is there a way to use the dll as a separate dependency and thus avoid unzipping that takes place during application launch?

Any help is appreciated. Thanks.

[Tres Finocchiaro]

Is there a way to use the dll as a separate dependency and thus avoid unzipping that takes place during application launch?

Quoting the javadocs:

> java.lang.Runtime.loadLibrary(String filename) method loads the dynamic library with the specified library name. A file containing native code is loaded from the local file system

Take note of "local file system".

You may be able to manipulate the PATH and provide it elsewhere, but this is arguably more work than whitelisting it through your security product. 

[Durchholz, Joachim]

We manually extracted the DLLs and and told the installer to include them in the installation package and unpack them during installation. (Maybe we could have asked the installer to do the extraction from the .jar while installing... we use a Java-based installer that can run code from the jar files being installed, so that would have been an option.)

JNA comes with a mechanism to use a preexisting DLL instead of extracting the included one.

 

Caveats:

• You need a different DLL, depending on platform.
• Aarch64 seems to be for ARM processors. (I was wondering, took me more than an hour to figure that out, and I’m not sure if I’m right.)
• The jar as available on Maven include all DLLs.
  If Carbon Black is complaining because the .jar contains DLLs, not because they’re extracted, the above approach won’t help (but then I don’t know what would help).

 

DLL handling indeed proved to be a hurdle to take. I’d have liked to see separate Maven artifacts for “JNA with extract-at-runtime DLLs” and “JNA with pre-extracted DLLs, JNA not even trying to extract them” (even having the code path is scary, I did some serious debugging to make 150% sure that that can’t happen, but I’d have to redo that with every JNA update so I don’t like that one bit).

 

Disclaimer: We could successfully make JNA work with that approach, and we validated that it in fact does not extract the DLLs, but we haven’t finished the path to actually building and distributing an installer package.

Validate what I’m saying before you rely on it (that’s generally what one should do for advice from the Internet, anyway ;-) )

 

Regards

Jo

--
You received this message because you are subscribed to the Google Groups "Java Native Access" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jna-users+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jna-users/ce60001e-30a1-45bf-be50-b6bf263bca70n%40googlegroups.com.

 

Sensitivity: C2 Internal

The content of this e-mail is intended only for the confidential use of the person addressed.
If you are not the intended recipient, please notify the sender and delete this e-mail immediately.
Thank you.