Is there anyway to sign RCP application so they get along with Bit9 (a security / application control system on Windows, see bit9.com)?

I have been given instructions to sign an EXE or DLL which I create. I can follow these instructions and sign the launcher application (eclise.exe for my RCP). That allows the launcher to execute.

bit9 stops the SWT*.dll unless it already has been give approval for that version and release (*). Any other ddl will be blocked by bit9.

The security department will give a user a half hour window to install an application. During this window unknown EXE and DLL are recorded and approved.

Does anyone have ideas how to live with this? I've searched both Eclipse.org and bit9.com for posts, articles or docs on how to improve the interaction between bit9 and Eclipse. No joy.

I was thinking that a class, or set of classes, that did nothing except to force the different DLLs in Eclipse to load would make the authorization process easier.

A complicated eclipse application, the eclipse IDE for example, may not touch all the DLLs it could touch (in /plugins) eventually. After loading the IDE this set of classes could be execute which would cause the DLL to be loaded and recoginized by Bit9.

I'd appreciate any references to documentation or experience anyone can share on this.

Signing an application and using that for approving files is one of the ways of approving files using Bit9 Parity. There are several other ways of approving applications.

I am an Engineer at Bit9 working on the parity product. I use Visual studio for development and have Parity on my development machine. We have provided solutions for similar cases for several of our customers. The best course of action would be ask your Bit9 Administrator to get in touch with his support person at Bit9. They will be able to provide the best solution for your case.

When creating an RCP the only Windows part that is created is the launcher, eclipse.exe or my_project.exe. The launcher can be signed.

The other DLLs which an RCP project uses are those provided by Eclipse and any third party plug-ins or jars (for example Java Advanced Imaging has 3 DLL so graphics can be handled with native mechanisms. The Eclipse DLLs are packaged in jar (Java Archive) files.

I doubt that Eclipse built-in security would allow removing the DLLs from the distribution jars, signing them and putting them back into the distribution jars.

Eclipse framework and Java loads DLL when it needs them. When Eclipse or an Eclipse RCP in installed on a Bit9 protected PC only the DLLs used by the install process, or called by running an Eclipse project or the Eclipse RCP during the installation time period, are recognized by Bit9.

DLLs called after the unlock period expires are blocked by Bit 9.

This is an example of the Bit9 / Eclipse problems we are having:

I received a new desktop with Bit9. Support put in the code to unlock the parity agent. I installed JDK 6 rel 32, copied IDE folder from my laptop to desktop and ran some of my projects.

The Bit9 app control error, block, occured when the IDE tried to use this DLL
C:\eclipse_ide\eclipse_indigo_RCP\configuration\org.eclipse.osgi\bundles\521\1\.cp\os\win32\x86\wbp.dll

I thought Bit9 would register more of these DLLs if I had a set of classes which touched each of these DLLs, forcing them to be unbundled for their delivery jar, and ran these classes during the installation while Bit9 was unlocked.

I am asking for other community members experience with Eclipse and Bit9.

There doesn't seem to be alot available now on getting Bit9 and Eclipse to work together. I didn't find anything on bit9.com for "Eclipse" and I didn't find anything on eclipse.org searching for "bit9" in terms of application control.

Resolving the issue will require involvement of the Bit9 Administrator at FIS. I also recommend that the remediation steps are done in conjunction with Bit9 support personnel. They would be more than happy to help implement the following steps.

1. Add *.jar files to the agent property file_patterns_to_deep_crawl and enable this agent prop.
2. Allow this configuration change to propagate to all agents.
3. Create a Trusted Directory and put the eclipse installer in the trusted directory.
4. Allow the approvals created as a result to propagate to all agents.
5. If you do not use trusted directories in your environment, it is recommended to delete the trusted directory created for the purpose.