Monday, April 24, 2017

Host your own eclipse signing server

We handled signing plugins with tycho some time ago already. When working in a larger company you might want to keep your certificates and passphrases hidden from your developers. For such a scenario a signing server could come in handy.

The eclipse CBI project provides such a server which just needs to get configured in the right way. Mikael Barbero posted a short howto on the mailing list, which should contain all you need. For a working setup example follow this tutorial.

To have a test vehicle for signing we will reuse the tycho 4 tutorial source files.

Step 1: Get the service

Download the latest service snapshot file and store it to a directory called signingService. Next download the test server, we will use it to create a temporary certificate and keystore.

Finally we need a template configuration file. Download it and store it to signingService/jar-signing-service.properties.

Step 2: A short test drive

Open a console and change into the signingService folder. There execute:
java -cp jar-signing-service-1.0.0-20170331.204711-10.jar:jar-signing-service-1.0.0-20170331.204711-10-tests.jar org.eclipse.cbi.webservice.signing.jar.TestServer
You should get some output giving you the local address of the signing service as long as the certificate store used:
Starting test signing server at http://localhost:3138/jarsigner
Dummy certificates, temporary files and logs are stored in folder: /tmp/TestServer-2590700922068591564
Jarsigner executable is: /opt/oracle-jdk-bin-1.8.0.121/bin/jarsigner
We are not ready yet to sign code, but at least we can test if the server is running correctly. If you try to connect with a browser you should get a message that HTTP method GET is not supported by this URL.

Step 3: Preparing the tycho project

We need some changes to our tycho project so it can make use of the signing server. Get the sources of the tycho 4 tutorial (checking out from git is fully sufficient) and add following code to com.codeandme.tycho.releng/pom.xml:
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

 <properties>
  <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
 </properties>

 <pluginRepositories>
  <pluginRepository>
   <id>cbi</id>
   <url>https://repo.eclipse.org/content/repositories/cbi-releases/</url>
  </pluginRepository>
 </pluginRepositories>

 <build>
  <plugins>
   <!-- enable jar signing -->
   <plugin>
    <groupId>org.eclipse.cbi.maven.plugins</groupId>
    <artifactId>eclipse-jarsigner-plugin</artifactId>
    <version>${eclipse.jarsigner.version}</version>
    <executions>
     <execution>
      <id>sign</id>
      <goals>
       <goal>sign</goal>
      </goals>
      <phase>verify</phase>
     </execution>
    </executions>
    <configuration>
     <signerUrl>http://localhost:3138/jarsigner</signerUrl>
    </configuration>
   </plugin>
   
  </plugins>
 </build>
</project>
The code above shows purely additions to the pom.xml, no sections were removed or replaced.

You may try to build your project with maven already. As I had problems to connect to https://timestamp.geotrust.com/tsa my local build failed, even if maven reported SUCCESS.

Step 4: Configuring a productive instance

So lets get productive. Setting up your keystore with your certificates will not be handled by this tutorial, so I will reuse the keystore created by the test instance. Copy the keystore.jks file from the temp folder to the signingService folder. Then create a text file keystore.pass:
echo keystorePassword >keystore.pass

Now we need to adapt the jar-signing-service.properties file to our needs:
### Example configuration file

server.service.pathspec=/jarsigner
server.service.pathspec.versioned=false

jarsigner.bin=/opt/oracle-jdk-bin-1.8.0.121/bin/jarsigner

jarsigner.keystore=/somewhere/signingService/keystore.jks
jarsigner.keystore.password=/somewhere/signingService/keystore.pass
jarsigner.keystore.alias=acme.org

jarsigner.tsa=http://timestamp.entrust.net/TSS/JavaHttpTS

  • By setting the versioned flag to false in line 4 we simplify the service web address (details can be found in the sample properties file).
  • Set the jarsigner executable path in line 6 according to your local environment.
  • Lines 8-10 contain details about the keystore and certificate to use, you will need to adapt them, but above settings should result in a working build.
  • The change in line 12 was necessary at the time of writing this tutorial because of connection problems to https://timestamp.geotrust.com/tsa.
Run your service using
java -jar jar-signing-service-1.0.0-20170331.204711-10.jar
Remember that your productive instance now runs on port 8080, so adapt your pom.xml accordingly.

Wednesday, March 15, 2017

Fancy tooltips

I always liked the tooltips available in eclipse editors. Having a browser widget that may capture focus is nice to display more complex help topics in the UI. Unfortunately the eclipse implementation is heavily bound to editors and cannot be used for other parts.

Well, up to now. For EASE I wanted to reuse these tooltips to display API documentation in a treeviewer. The result looks quite satisfactory:


I built some API to add these tooltips to any kind of SWT controls. While it may not be perfect it seems rather simple to use for me.
  final HoverManager hoverManager = new HoverManager(parent);
  hoverManager.addHover(fModulesComposite.getTreeViewer(), new IHoverContentProvider() {

   @Override
   public void populateToolbar(BrowserInformationControl control, ToolBarManager toolBarManager) {
    // nothing to do
   }

   @Override
   public String getContent(Object origin, Object detail) {
    return "<p>This is HTML content</p>";
   }
  });
To see these tooltips in action get a nightly build of EASE and open the Modules Explorer view.

Now I am wondering if there is any interest in making this API available for other eclipse projects.
When extracting the functionality I had to access some internal classes from org.eclipse.jface.text and JDT - mostly because of package private methods. Porting back these changes would be possible, still I am wondering if org.eclipse.jface.text would be the right place for it. Why should a generic view depend on jface.text just to get nice tooltip support?

So lets see if there is interest in adopting this feature and where to put it.