Unsigned Jars in 5.1.2

Morning All,
I have a problem after I upgraded our Servoy Production Server to 5.1.2
The machine its running on is a MAC OS X Server Ver. 10.5.2. It has done all the latest system updates.
On the previous version of Servoy 5.1.1 we had certain Mac clients with who’s os systems are 10.5 or lower did not load up due to an certificate error.
So we thought the 5.1.2 update should fix this. Last night I did the update and when I try to launch any client I get errors saying that the plugins and beans need to be signed.

com.sun.deploy.net.JARSigningException: Found unsigned entry in resource: (http://192.168.1.9:8080/beans/slider.jar, 1223972145000)
at com.sun.javaws.security.SigningInfo.getCommonCodeSignersForJar(Unknown Source)
at com.sun.javaws.security.SigningInfo.check(Unknown Source)
at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(Unknown Source)
at com.sun.javaws.LaunchDownload.checkSignedResources(Unknown Source)
at com.sun.javaws.Launcher.prepareLaunchFile(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.prepareToLaunch(Unknown Source)
at com.sun.javaws.Launcher.launch(Unknown Source)
at com.sun.javaws.Main.launchApp(Unknown Source)
at com.sun.javaws.Main.continueInSecureThread(Unknown Source)
at com.sun.javaws.Main$1.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)

I have read the post http://forum.servoy.com/viewtopic.php?f=15&t=13974, posted earlier this month, and shouldn’t the 5.1.2 fix this issue of jars having to be signed?
How do I fix this issue? do I have to go through and sign ALL the jar files? I have run ‘signtester.jar’ and most of the jars we have are unsigned for some reason.

Thanks in Advance,

Are you sure slider.jar is signed?
If so, try to clean you webstart cache once.

I have uploaded a sign version of all beans/plugins on my site, you need to download a signed version or use the tool that Johan did: see http://forum.servoy.com/viewtopic.php?f=15&t=13974#p73294

You guys should really put a permanent link on the iServoy page that link to the explanation and tools.

And/or set a page on the wiki. You are going to have lots of messages like this one, it would be good to direct people to a clear explanation and download instead of a forum discussion.

My 2 cents.

Got it to work, thanks guys. I agree with Patrick. You should really have main thread on this. As soon as people start upgrading they will be asking the same question for sure! :)

This is ridiculous. every client that starts up need 10+ certificates to be accepted. And to accept them permanently an administrator has to go around and enter the admin password on 50+ clients we have in our company. and that includes every time they clear their caches. Even after the update, initially, our administrator had to go around and clear caches on all our client computers. Also the problem of 10.5 client and below still cannot log in to the system without certificate errors. I’m switching back to 5.1.1 until I get a proper fix.

OMG!!!
What a mess up!
I just updated a client to 5.1.2 and now get this unsigned issue.
I DO NOT have time to fiddle around signing beans and plug-ins and the Java version is 17, not even 19!!!
How can I get 5.1.1 or even 5.1.0 which they were on?

I am not happy as my client was just about to do some final testing before going live and unless I sort this out tonight, they won’t even be able to launch Servoy!!!

NOT HAPPY!

problem is that you dont know what your clients do have…
Java updates are automatically pushed down to the clients.

But just run my tool once with your own certificate, and update the jnlp files that they have all permissions tag.
(i will see if that last step i can do automatically also)

If you use 5.1.1 or lower then you should remove swingbeans.jar from your server\beans dir
and the clients that do upgrade or install a new version, they should go to the java control panel and in the advanced tab go the the security node → mixed code > and select the second checkbox (hide warning but run code)

But self signing your 3th party plugins is a few minutes work…
the only extra thing that is a bit of work is what i did say above is that of those 3th party plugins you should look if they have jnlp files and you have to add this

<security>
		<all-permissions/>
	</security>

just above the tag

@Vaj: a client shouldnt need to accept 10+ certificates… Servoy’s in a trusted one that doesnt need to be accepted, and if you have 3th party plugins/beans from for example it2be those will also be trusted
Only then what is nog signed after that and signed with your (or the plugin itself) self certificate needs to be accepted onces.
It is weird that you need to flush your cache. That shouldnt be needed because of all this signing all jars are touched and brand new. So webstart should download them all.
Did you have servoy.fastClientStartup enabled? (because this can result in a bit more caching on the client side)

jcompagner:
for example it2be those will also be trusted

100% correct but only after updating (you can read more here: http://www.it2be.com/index.php/componen … rvoy-4-a-5)

Johan,
I have signed all the jars. I ran the jar file you provided. and it said most of the Jars I had were unsigned.
Then I ran keytool -genkey -keystore mykeystore -alias MyPlugins -validity 10000. then signed the jars with the key using the signtester.jar
1st attempt on client side : not signed error → cleared cache → works, but I had to go through and accept a lot of certificates. the certificates were called ‘FDEG’ have no idea what this is. eventually it loads up. takes a very long time. This was a windows machine.
On macs >= v10.6, same behaviour. but to accept a certificate permanently an admin pw is needed, so normal users cant do this.
On macs <= v10.5, doesn’t load up at all. Certificate error.
servoy.fastClientStartup is set to False. So really don’t understand what is happening.
Any Ideas?

Vaj:
But I had to go through and accept a lot of certificates. the certificates were called ‘FDEG’ have no idea what this is. eventually it loads up. takes a very long time. This was a windows machine.

What are the unsigned jars? It would help a great deal when you mentioned that!

Vaj:
On macs >= v10.6, same behaviour. but to accept a certificate permanently an admin pw is needed, so normal users cant do this.

That probably has to do with where you installed Servoy in combination with the settings of Java security for the client

Vaj:
On macs <= v10.5, doesn’t load up at all. Certificate error.

That is really strange, what certificate generates the error?

I have never had such a problem with a Servoy update :(
To save me having to ‘sign’ all the jars, I tried to uninstall 5.1.2 and then put on a clean install of 5.1.0.
I then had to re-install my IT2Be stuff (Calendar & Tools) and Dr Maison plug-ins (the free ones…), but I then had various issues with different things still being unsigned (& this was all on a PC with release 17 of Java 6, not 18 or 19) or plug-ins not appearing, even though they were installed (Calendar).
Eventually, after copying over the files from my Mac to customer’s PC server, I managed to get a local client to launch, but now other users are not able to launch there and I have had to ask their IT dept. to try and help me as I am at another client today!!! :( :( :(
Next time, and for everyone else, I will make sure to stop Servoy, back up the WHOLE Servoy directory (databases are elsewhere, so not too big), do the update and then if there is a problem, I should have a working copy still…
I really don’t understand why my re-install didn’t just work again…

Johan, did you check that your new 5.1.2 update worked with older Java releases still?

Thanks,

Rafi

For those of you using plugins from us (servoy-plugins.de), we have now signed all of our components with a self-signed certificate. You can download an updated installer from our website.

We have bought a real certificate, but that has not yet been issued. In a few days we hope to provide another update with the real certificate that will not present a dialog to the user (for our components at least).

rafig:
Johan, did you check that your new 5.1.2 update worked with older Java releases still?

5.1.2 on a XP machine with a java u18 install works fine for me
Even with some plugins and beans installed of it2be (that are now signed by a trusted certificate)

Because it2be does use extensions now with there own signing, it will come up with a information (not warning!) dialog
that you also are going to install an extension. This dialog you only get once, even after you do clean cache and reinstall everything again you will not see it again.

I only get a dialog once for a self signed certificate, So it seems users that don’t have any permissions somehow webstart can’t store that info and will ask it again and again.
Are these the same as users that can accept permanently that self signed signature?

There is a problem with plugins that have there own jnlp file with other jars and in that jnlp file there is a hard version number that isn’t altered after the signing.
Then webstart things there is nothing changed. I have fixed that so that that version number is always the date of the jar file.
We will release this asap.

I will try to setup an environment with a user with very little privileges to see if i can reproduce this and will create bug reports to sun that such a user should also be able to accept it permanently (purely for his account)

jcompagner:

rafig:
Johan, did you check that your new 5.1.2 update worked with older Java releases still?

5.1.2 on a XP machine with a java u18 install works fine for me

Yes, but what about r17? This is what this client had…
I had tried to advise my clients not to update past 17, even though some did go to r18 or even r19

jcompagner:
Even with some plugins and beans installed of it2be (that are now signed by a trusted certificate)

Because it2be does use extensions now with there own signing, it will come up with a information (not warning!) dialog
that you also are going to install an extension. This dialog you only get once, even after you do clean cache and reinstall everything again you will not see it again.

I only get a dialog once for a self signed certificate, So it seems users that don’t have any permissions somehow webstart can’t store that info and will ask it again and again.
Are these the same as users that can accept permanently that self signed signature?

There is a problem with plugins that have there own jnlp file with other jars and in that jnlp file there is a hard version number that isn’t altered after the signing.
Then webstart things there is nothing changed. I have fixed that so that that version number is always the date of the jar file.
We will release this asap.

I will try to setup an environment with a user with very little privileges to see if i can reproduce this and will create bug reports to sun that such a user should also be able to accept it permanently (purely for his account)

I don’t think it was an issue with account privileges, as I was logged in as a user with Admin rights, as I need to be able to configure Servoy, services etc.
Basically, once I saw the signing isue and this thread, I did the re-install of old Servoy 5.1.0 and THEN had issues with signing of stuff, even though it had all been working before, but these could have been down to the 3rd party stuff, as I used their newest installers, which may have been updated to cope with Sun Java signing rubbish like you did, but on older Java’s caused a problem…

Anyway, it seems like the IT guy at my client has managed to ‘fix’ things by (I think…)
Deleting all Java caches
Deleting ‘.servoy’ directory
Deleting ‘Application Data/Sun’ directory
Un-installing Java and then re-installing Java r17 (and making sure ‘Direct Connection’ is set in Network’ bit…)

Phew!

Anyway, I will now be more careful about how I go about updating clients Servoy Servers… :wink:

Rafi

but on older Java’s caused a problem…

This can never happen as far as I know.

Signing and security settings as they are now for IT2BE Components as well as for Servoy (the rest I don’t know) is something that could be done already.

It is not like this is something new. In fact, this was already done for some of our Components from the beginning (but with a self-signed certificate)!

The only thing new here is how Java now deals with unsigned jars and jars with self-signed certificates.
We are now forced to sign when we want to avoid the dialog issue.

So, in short (and correct me if I am wrong) the signing thing is not to create issues but to solve them and will (or let me be more careful: should) not give any issue, other than one informative dialog per developer certificate.

Oh and Rafig, didn’t I mention that you should create a backup and test on your developer machine first ;)

IT2Be:

but on older Java’s caused a problem…

This can never happen as far as I know.

Signing and security settings as they are now for IT2BE Components as well as for Servoy (the rest I don’t know) is something that could be done already.

It is not like this is something new. In fact, this was already done for some of our Components from the beginning (but with a self-signed certificate)!

The only thing new here is how Java now deals with unsigned jars and jars with self-signed certificates.
We are now forced to sign when we want to avoid the dialog issue.

So, in short (and correct me if I am wrong) the signing thing is not to create issues but to solve them and will (or let me be more careful: should) not give any issue, other than one informative dialog per developer certificate.

OK, thanks. I must have done something else wrong…

IT2Be:
Oh and Rafig, didn’t I mention that you should create a backup

noobie error :wink:

IT2Be:
and test on your developer machine first ;)

No issues on my (Mac) developer as I don’t think Java is involved in the same way when launching Developer Debug Client… (and my Mac is using whatever old version of Java Apple deems acceptable…)

Rafi

I have run the whole signing process on a different test box. I have attached the my unix terminal outputs.
It shows that all the unsigned jars get signed after the process.

The certificates now don’t pop up as much as the first time I tried. I get the servoy certificate which I have to accept only once any ways. and then two other certificates from third party beans/plugins. one for JPedal PDF preview bean (IDR Solutions) and another called FDEG! which I have no clue what it is.
I am guessing the JPedal guys should be releasing a signed version of their bean. and I’m gonna now sit down and clear the beans and plug-ins folders to get rid of whatever that FDEG certificate was. This should pretty much clear my problems with Certificates.

So the only issue I have now is the versions below os x 10.5 still not launching.
Error I get on versions below 10.5 is as follows. (even after cache is cleared) refer also client_err.jpg

JNLPException[category: Launch File Error : Exception: null : LaunchDesc:

Data Plug-in IT2BE Java Development Data Plug-in for Servoy An IT2BE Component to add additional functionality to Servoy. ] at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LaunchDownload.java:1041) at com.sun.javaws.LaunchDownload.checkSignedResources(LaunchDownload.java:943) at com.sun.javaws.Launcher.continueLaunch(Launcher.java:843) at com.sun.javaws.Launcher.handleApplicationDesc(Launcher.java:527) at com.sun.javaws.Launcher.handleLaunchFile(Launcher.java:219) at com.sun.javaws.Launcher.run(Launcher.java:166) at java.lang.Thread.run(Thread.java:613)

Terminal Saved Output.txt (28.5 KB)

That is an old jnlp file Rafi.

Possible causes/solutions

  1. You updated the data plugin but the jnlp still resides in cache (very very unlikely): clear client cache
  2. You did not update the data plugin: update it or remove jars and folders in the plugins folder that start with it2be-data
  3. Take a break, get drunk and start all over again.

You can check the contents of the jnlp file btw. When the jnlp file in the plugins folder differs from that in the exception it is cache.
The current version is 4.1-043.

IT2Be:
That is an old jnlp file Rafi.

Not me, Marcel, check poster, it was Vaj…
:wink:

Rafi