aspose file tools*
The moose likes Security and the fly likes Signing native code? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » Security
Bookmark "Signing native code?" Watch "Signing native code?" New topic
Author

Signing native code?

Mike Dahmus
Greenhorn

Joined: Mar 07, 2002
Posts: 29
A lead engineer in my new company wants the new DLL (that I use to access the Windows registry - downloaded from an existing applet) to be signed, as is the jar with the applet itself.
I'm flummoxed - after 45 minutes with google, I can't find anybody doing this in any other environment than ActiveX.
Anybody ever dealt with this requirement? We already have all the certificates we need, I think; I just need some mechanical (and tool) help with the signing of the native-code DLL piece of it.
Thanks,
Mike Dahmus
mdahmus@io.com


-----Mike Dahmus mike@dahmus.org
Rufus BugleWeed
Ranch Hand

Joined: Feb 22, 2002
Posts: 1551
If you signed the jar the dll is delivered in, credibility of the dll is ensured. Did I read you correctly that the dll is delivered in the jar?
Mike Dahmus
Greenhorn

Joined: Mar 07, 2002
Posts: 29
Nope. The jar executes, determines local platform, and (if Windows) downloads the JNI DLL. Then and only then does it execute the java code backed by the JNI DLL.
(Obviously my jar is running with all possible privileges at this point).
Packaging the DLL inside the jar - never thought of this. It would add unnecessary download time on unix boxes, but that might not be a deal-breaker... any problems to look for here?
Mike Dahmus
Greenhorn

Joined: Mar 07, 2002
Posts: 29
Another problem which has presented itself:
The path is like this, simplified:
1. Download DLL - this sticks it in the user's desktop on Windows (guh)
2. Execute code which calls DLL
3. Try (and fail) to delete DLL (to clean up user's desktop).
How can I, after 2, relinquish my hold on the DLL so it may be deleted?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16068
    
  21

The problem with "signing" a DLL is that DLLs weren't originally designed to be signed. However the difference between a DLL and an ActiveX control is mostly illusory.
It doesn't really matter what you set in java security once you drop into JNI, as there's no way the JVM can keep native code honest. So the only actual Java security rules you need to set are those needed to be able to invoke the JNI code.
If you're simply interested in manipulating the Windows registry in Java, however, I think you're re-inventing the wheel.
BTW, there is an unload DLL function in Windows. I forget the exact name and calling, however. If I've not got my OS's confused, it decrements the DLL use count and only unlocks the DLL when the number of users hits 0.
[ March 26, 2004: Message edited by: Tim Holloway ]

Customer surveys are for companies who didn't pay proper attention to begin with.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Signing native code?