As you might have noticed Oracle/Sun change the security level requirement in a minor update.
This change requires to:
Have all beans/plugins signed with a certificate (a self signed certificate will suffice, but does result in warning for enduser, which is better to avoid)
Change the dedicated plugin jnlp file if used, it needs to contain:
In the future we might be able to drop these requirements with use of classloaders and the new jar manifest options provided in Java 6 update 19, we are researching this currently.
Jan Blok:
In the future we might be able to drop these requirements with use of classloaders and the new jar manifest options provided in Java 6 update 19, we are researching this currently.
But I assume/hope we don’t have to remove the signatures anymore now the work is almost done for us…
We will keep supporting signed plugins.
The only thing is that we need to look for plugins without there own plugin.jnlp if we need to generate in the jnlp or not (unsigned can’t have that and signed need it…)
so the first argument must point the the keystore file you made with the keytool
the second argument must be the password you entered when creating the keystore.
the third argument “MyPlugins” must be the same as the -alias MyPlugins argument of the keystore (you can change this name if you want)
So. What you are saying is that it is possible for developers that create their own in-house plugins/beans or use third-party plugins/beans that are unsigned it is possible to sign the plugins and beans themselves?
yes but with a self signed certificate
So you will get a warning dialog about that (not the new warning dialog but the warning dialog we always had when using self signed)
The good thing about this warning dialog is that that one has an accept always checkbox… So you only have to accept it once with the first download.
(and that dialog doesnt hang with 6_u19)
does this work also the same way in a Servoy 3.5 environment?
I’m getting a long long list of not signed plugins/bean in Servoy (non servoy plugins/beans)
jcompagner:
We will keep supporting signed plugins.
The only thing is that we need to look for plugins without there own plugin.jnlp if we need to generate in the jnlp or not (unsigned can’t have that and signed need it…)
What about beans? Will they also be loaded by this classloader you talk about?
How will you know if they are? Will you check the jar and have 2 different classloaders?
I’m curious.
Anyway, nice little tool you did, thanks.
I see that you have shipped a lot of java tools - including javac/javadoc/applet etc. - with it, why is that?
I ran the above signtester.jar from my application_server directory, It is reporting almost all the jars present in the beans, plugins and lib directory. Do I have sign all the jars, including those, coming with servoy as well??? Or Servoy is going to provide the signed jars for those that are used by Servoy itself??
In that case your observation makes sense.
I don’t know if you realize you are reading this in ‘Plugins and Beans’?
Anyway, you should read the following ‘Announcements’ post because that will give you an answer: viewtopic.php?f=16&t=13976
I don’t know if you realize you are reading this in ‘Plugins and Beans’?
Anyway, you should read the following ‘Announcements’ post because that will give you an answer: viewtopic.php?f=16&t=13976
I have not seen that announcement thread. Thanks for notifying me.
for 3.5 are you suggesting that a new build is needed. If so when will this be available?
Sorry, 80% of this is going above my head, as servoy 3.5 has always worked out of the box just by installing the plugins from whichever developer i have purchased them from. The whole situation is slightly worrying.
ptalbot:
How will you know if they are? Will you check the jar and have 2 different classloaders?
I’m curious.
thats something i need to figure out…
on the server i could try to read out the file and see if it is signed. And if it is generate X and if it isnt generate Y
(this is only important for plugins without a jnlp and beans)
Plugins with a jnlp it simple, they generate there own jnlp and should if they sign use the all permissions entry else if they dont sign
then dont use that entry. So the problem is what to do with plugins (and beans) where we generate the jnlp for…
If they are signed then we need to use if they are not we cant generate that…
all plugins and beans are loaded through Class.forName() kind of syntax, we just need to give a right classloader with it (and i dont think this matters of it is signed or unsiged)
ptalbot:
Anyway, nice little tool you did, thanks.
I see that you have shipped a lot of java tools - including javac/javadoc/applet etc. - with it, why is that?
Its just the tools.jar of a java 6 install, added with 1 class and a manifest with a main attribute so it is very easy for people to use.
Didnt want to extract exactly what i needed because that is quite hard to find…
I see! Thanks for your answers.
What about beans that have dependencies? Right now, for the SVGBean for example, I add a dummy plugin with a jnlp to be able to load the batik jars, but of course these need to be signed, so I guess the safest approach is to sign the bean jar as well, isn’t it?
I put a link to your post/tool on my FAQ for people who wants to sign the jars themselves.
Suggestion to Paul:
I think that you should put a permanent download link to this tool with the explanations somewhere (on the wiki perhaps?), because it will happen to people in the future and they will not know where to find the information buried in the forum.
if you have a bean that needs some external jars.
You dont need to also create a dummy plugin.
Just do it the bean way with adding the classpath manifest attribute and point to your 2 other jars there in the manifest of your bean.jar
Those external jars also need to be signed yes (with the same certificate!)
And in servoy 5.1.2 you will see that we generate a jnlp file for that bean that has 1 jar reference to your bean.jar and 1 or more jar references to the jar the bean jar depends on.
jcompagner:
if you have a bean that needs some external jars.
You dont need to also create a dummy plugin.
Just do it the bean way with adding the classpath manifest attribute and point to your 2 other jars there in the manifest of your bean.jar
Those external jars also need to be signed yes (with the same certificate!)
And in servoy 5.1.2 you will see that we generate a jnlp file for that bean that has 1 jar reference to your bean.jar and 1 or more jar references to the jar the bean jar depends on.
If I add the external dependencies in a subfolder, with a classpath pointing on it, will it work?
For the SVGBean, the Batik framework is subdivised in 17 little jars (and I don’t have them all), so if I put all this directly in /beans its going to be a big mess!