I’m trying to use signtester.jar to sign my jars. But it doesn’t seem to work.
It seems to detect the unsigned jars but when I try to sign them using the keystore I have just created it doesn’t seem to be able to sign them.
Here is an example (it’s doing this for every jars):
//signtester without parameter
...
Verifiying dir: .\plugins\it2be-outlook
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-outlook.jar didnt verify
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-splash.jar didnt verify
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-tools.jar didnt verify
...
//signtester with keystore in parameter
...
Verifiying dir: .\plugins\it2be-outlook
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-outlook.jar didnt verify
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-outlook.jar still not signed, is it double signed?
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-splash.jar didnt verify
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-splash.jar still not signed, is it double signed?
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-tools.jar didnt verify
C:\Program Files (x86)\Servoy\application_server\.\plugins\it2be-tools.jar still not signed, is it double signed?
...
it could be that those are double signed or something now.
For those you have to remove the signing out of the jar file your self
This means deleting the 2 files in \META-INF\ that ends with .rsa and .sf
and then update the manifest.mf deleting all the lines with:
Name: xxx.class name (or other resource)
SHA1-Digest: XXXXXX
with plugins this mostly means from the first line that that is starting you can delete everything from there to the end
With beans you have to be more careful because there you can have a Name: xxx entry that also has a line:
Java-Bean: True
then the name:xxx must be kept including the java-bean and only the SHA1 can be removed.
But maybe the easiest thing to do is to wait for it2be to give you its updated plugins
I think that is pretty much done.
I run into that too, and it has nothing to do with double signing (althought it could):
You need to do that WHEN SERVOY IS NOT running, I don’t think this is obvious for people, if you do it while the server/developer is running the jars are locked (at least on windows)!
ptalbot was right. When I tried I still had the server running.
Now it seems to have signed everything and when I run a check again no jar is highlighted as “not signed”.
However, after clearing my cache, when I try to connected I still have the error message with the swingbeans.jar bean. And when I look on the server under the beans folder I see that swingbeans.jar has not been changed (last modification date didn’t change).
But swing beans cant really be signed at least there is not really something to sign (there are no classes)
But Servoy 5.1.2 will not serve out the swingbeans.jar (or any jar like that like it2be calendar bean) to the client
So your smart client shouldnt get that one at all.
To make it clear, we are currently running on Servoy 5.1.1 and need to fix it with this version or earlier as we have customers still running on 4.1.4.
So if your tool skips jars like swingbeans.jar, yes it’s normal that we still have a problem it.
Jan Blok:
The tool works only in conjunction with Servoy 5.1.2 and 4.1.6 (and upcomming 3.5.11)
So the best solution for people who cannot upgrade Servoy quickly and have Java 6 Update 19 or more on their machine, is to downgrade to update 18 and wait for the update of Servoy to be done?
Jan Blok:
If you cannot upgrade Servoy to the latest version, yes you have to install a Java lower then Java 6u19.
I don’t get your comment:
Foobrother:
and wait for the update of Servoy to be done?
We released 5.1.2 and 4.1.6 already, last week…as a response to Sun’s unannounced security level change.
I was just asking if the best solution was to stay on/downgrade to update 18 until an admin installs the Servoy update.
I know you guys have quickly released a new version to fix this issue and I thank you for that. But I was just wondering If there was a solution for people who cannot install Servoy update quickly (we have customers who need 2 months to run security tests procedures to allow an update on their production servers)
the other solution is if you are upgrading to u19 (if that is automatic or something)
then with a older servoy release it will still work. Only 2 things need to be done:
delete the swingbeans.jar from the beans dir (and also the it2be calendar bean and so on) on the server
And for clients with u19 you have to go to the java control panel and under the advanced tab → security → mixed mode
select the 2nd (hide warning but run with protections) or last checkbox (disable verify completely)
for a customer of us, who hosting his solution on our server, we have upgraded the servoy application_server from 5.1.1 to 5.1.2 by using the servoy_updater.bat
no third party plugins, or what so ever.
but now, if we start the solution, (rather on Mac, with a lower version of Java 1.6 or on Windows) we get this error:
com.sun.deploy.net.JARSigningException: Niet-ondertekend onderdeel gevonden in resource: (http://87.249.xxx.xxx:8089/lib/commons-httpclient.jar, 3.0)
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(SigningInfo.java:382)
at com.sun.javaws.security.SigningInfo.check(SigningInfo.java:256)
at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LaunchDownload.java:1384)
at com.sun.javaws.LaunchDownload.checkSignedResources(LaunchDownload.java:1170)
at com.sun.javaws.Launcher.prepareLaunchFile(Launcher.java:1033)
at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:309)
at com.sun.javaws.Launcher.prepareToLaunch(Launcher.java:186)
at com.sun.javaws.Launcher.launch(Launcher.java:107)
at com.sun.javaws.Main.launchApp(Main.java:405)
at com.sun.javaws.Main.continueInSecureThread(Main.java:252)
at com.sun.javaws.Main$1.run(Main.java:111)
at java.lang.Thread.run(Thread.java:637)
exactly the same kind of problem but then with another plugin.
Problem is that to get it right you have to go over all plugin.jar.jnlp files and up the version=xxx if it has a number or fixed value in there.
The jar change is most of the time noticed by Java webstart AND tests takes place in a clean env. to prevent contamination (which means there is no problem to begin with)
In other words clearing the webstart cache also works.
jcompagner:
the other solution is if you are upgrading to u19 (if that is automatic or something)
then with a older servoy release it will still work. Only 2 things need to be done:
delete the swingbeans.jar from the beans dir (and also the it2be calendar bean and so on) on the server
And for clients with u19 you have to go to the java control panel and under the advanced tab → security → mixed mode
select the 2nd (hide warning but run with protections) or last checkbox (disable verify completely)