Issues with unsigned commons-httpclient.jar

Classic Servoy
1

Running smartclient on a PC with JRE 6u15 (ie NOT 6u19 with the security issues).
Also tried on JRE 5u15 and 6u17.

When I try to start the SC I get the following message:

An error occurred while launching/running the application.

Title: Servoy Client - servoy-client
Vendor: Servoy
Category: Security Error

Unsigned application requesting unrestricted access to system
Unsigned resource: https://server.com:443/lib/commons-httpclient.jar

Now as far as I know commons-httpclient.jar is a built-in (servoy) jar file? (please correct me if I am wrong)
I certainly dont recall having installed it separately.
I know about the issues with unsigned jars in later JRE - but why am I seeing this in earlier versions?

Should I follow the ‘signing’ routines identified in other posts related to 6u19 - or is this a different issue?

Thanks
Al

2

The problem is that your client is still using the cached (unsigned) version of the plugin.
To force it to use a new version you will have to open the http.jar.jnlp with a text editor, and change this:

     <jar href="/lib/commons-httpclient.jar" download="%%loadmethod%%" part="httpclient" version="3.0"/>
      <jar href="/lib/commons-codec.jar" download="%%loadmethod%%" part="codec" version="1.3"/>

by that:

      <jar href="/lib/commons-httpclient.jar" download="%%loadmethod%%" part="httpclient" version="%%version%%"/>
      <jar href="/lib/commons-codec.jar" download="%%loadmethod%%" part="codec" version="%%version%%"/>

The %%version%% here is important! It will be replaced by Servoy with a new version number, and only then your client will see that there is a new one and will download the signed version instead of using the one he has.

Servoy knows about this issue and they will most certainly correct this in next version.
In the meantime, I will advise everyone to check all the jnlp files and replace any fixed version number with %%version%% to avoid anymore problems with other libs.

3

Hi Patrick,

in your latest version of the browsersuite we also still see some fixed version numbers…
should’t this be fixed/changed than also?

4

with the next release of 5 this is fixed in servoy itself, for all jnlp files that servoy serves to the client
we will rewrite the jnlp file so that they are correct and updatable.

5

Harjo:
Hi Patrick,

in your latest version of the browsersuite we also still see some fixed version numbers…
should’t this be fixed/changed than also?

Hi Harjo,
I know, I will update the BrowserSuite and all the plugins and beans I made as soon as I have the trusted certificate that I have requested, expect this within a day or two.
I will also update the number in the jnlp so that you will not have to do that yourself.

6

So what do I do if I’m getting this error on a plugin that does not have a .jnlp file?

We’re on 4.1 and Windows 7

7

what error do you exactly get?

You just have a signed plugin.jar that doesnt need other jar files so it doesnt have a jnlp?
Then it should work fine, servoy will generate a jnlp for you, but the jar file must be signed.

8

I get the same error…

Unsigned application requesting unrestricted access to system

and then it lists the plugin or bean.

So how do I “sign” a bean?

9

http://www.servoy.com/forum/viewtopic.p … 974#p73294

10

Look here for a comprehensive guide to signing unsigned libraries:
http://wiki.servoy.com/x/SpV7

Paul

11

Hello All,

So we’ve had quite the day moving our server to 4.1.6 in order to handle the issue with Java’s new update. At this point, clearing the user’s java cache usually does the trick, but we’ve come across an issue with a Mac User on 10.4… PowerPC… they can’t launch the smart client. They get an error at launch.

See image attached.

[attachment=0]java_error.jpg[/attachment]

So are we in a touch spot here? Anyone have any ideas to get this client rolling today?

Keep in mind that we have cleared the users Java cache,
We’ve tried updating to the newest Java (it appears Java 5 is the highest it will go in 10.4)

Thanks,

Chico

java_error.jpg
java_error.jpg1440×900 279 KB

12

If you go to the ‘Launch File’ tab, you should see which jnlp is the offender, once you get that, check the codebase attribute of the jnlp node in that file, it seems that it contains 2 “%%serverURL%%” value.

13

It’s not really visible in the screenshot but the error is:

The field <jnlp>codebase has an invalid value: %%serverURL%%

Which is in the jnlp of the core-common.jar. An component of the IT2Be Data plug-in (2.6-50)

Hope this helps you to get a better answer.

Edit: I guess the error was visible after all, just that when you click on it the scrollbars are gone and not all of the image is visible.

14

So this is an it2be issue? Marcel are you lurking around? :)

15

we do replace %%serverURL%% in the jnlp files. You shouldnt really get that one
But it could be that marcel has an extension jnlp file that is targetted like: /plugins/somejardir/some3thpartyjnlp.jnlp

And in those jnlp files we cant replace %%serverURL%% because that doesnt go through our servlet. (its a direct file access from the server)

The url of that jnlp file should be:

/servoy-client/plugins/somejardir/some3thpartyjnlp.jnlp

Then it will be parsed by us

In the next version of servoy (5.1.3) we will generate that all for you so that it will always be corrected on the server side.

16

I had the same problem. Marcel was informed about it 2 weeks ago.

I could solve this problem when updating java to 1.6 update 17.
For older versions of Java (for example 1.6 update 7 or even 1.5 the error occurs)
I upgraded all customers to 1.6 update 17 when it was possible.

17

yes older then u14 have a problem with double signing.

So i guess there are some jars now that have double signing and u13 can’t handle this. It thinks that the jars are not signed with the same certificate (which i wrong because it is signed with the same but also with another)
it seem that u15 (and maybe u14) fixed this.

But if you find such a jar then i would say let the maker of that jar know that it is double signed, because then it can delete the other signing so it only has 1 signer so that it works in u13 and lower.

18

I had the same issue with an 5.1.0 install with the latest it2be plugins.
The it2be-core has a jnlp that links to the Servoy /lib/log4j.jar. Since this is 5.1.0 it’s not signed and it2be’s stuff is so it barfs.
I had to hack out the log4j resource reference in the it2be jnlp to get it going again.
Not the best ways to fix things but it had to be done, it’s a production server.

19

The problem that martin has is this:

we do replace %%serverURL%% in the jnlp files. You shouldnt really get that one
But it could be that marcel has an extension jnlp file that is targetted like: /plugins/somejardir/some3thpartyjnlp.jnlp

. I will solve that today or tomorrow.
The problem that robert described is something that I am evaluating right now.

20

Awesome Marcel! It is appreciated.