OLD FORUM - Use new one: https://www.CaptainCasa.online/forum

From 2014 on CaptainCasa only comes with officially signed JAR client side jar files.

If you want to use own signatures you may use the followin ANT script for re-signing a jar:

Code:

 <project name="Resign jar file" default="RESIGNJARFILE">
 
     <description>Unsign a jar file</description>
 	
     <property name="my.keystore" value="CompanyXYZ"/>
     <property name="my.alias" value="CompanyXYZ"/>
     <property name="my.storepass" value="harry123"/>
     <property name="my.storetype" value="JKS"/>
 	<!-- 
 	The properties are referring to a self generated keystore CompanyXYZ 
 	that is located in the same directory as this script. 
 	
 	Create keystore via following batch file:
 	
     set JAVA_HOME=c:\bmu_jtc\jdk
     call %JAVA_HOME%\bin\keytool -genkey -keystore CompanyXYZ -alias CompanyXYZ -validity 10000
 	
 	Specify password "harry123" when creating the keystore.
 	
 	We do not recommend the usage of self-generated keystores!!!!!!
 	-->
 	
 	<macrodef name="macroResign">
 		<attribute name="jar"/>
 		<sequential>
 	        <delete dir="temp" failonerror="false"/>
 	        <mkdir dir="temp"/>
 	        <unjar src="@{jar}" dest="temp">
 	            <patternset>
 	                <include name="**"/>
 	                <exclude name="META-INF/*.SF"/>
 	                <exclude name="META-INF/*.DSA"/>
 	                <exclude name="META-INF/*.RSA"/>
 	            </patternset>
 	        </unjar>
 			<delete file="@{jar}" failonerror="false"/>
 	        <jar destfile="@{jar}"
 	             basedir="temp"
 	             includes="**"
 	             manifest="temp/META-INF/MANIFEST.MF"/>    
 	        <delete dir="temp" failonerror="false"/>
             <signjar jar="@{jar}"
                      keystore="${my.keystore}"
                      alias="${my.alias}" 
                      storepass="${my.storepass}" 
                      storetype="${my.storetype}"/>
 		</sequential>
 	</macrodef>
 	
     <target name="RESIGNJARFILE" description="Resign jar file">
         <macroResign jar="C:\bmu_jtc\eclipse\workspace\eclnt_client\ztemp\result\eclnt.jar"/>
     </target>    
     
     
 </project>

Please take care, that ANT is called by some JDK, not by some JRE! (Otherwise you will get some file not found exception.)

Regards, Björn

Hello Björn,

it does only a half job. Don't forget:

Code:

    
 <manifest file="temp/META-INF/MANIFEST.MF">
                 <attribute name="Permissions" value="all-permissions" />
                 <attribute name="Codebase" value="*" />
                 <attribute name="Application-Library-Allowable-Codebase" value="*" />
                 <attribute name="Caller-Allowable-Codebase" value="*" />
                 <attribute name="Trusted-Only" value="true" />
                 <attribute name="Trusted-Library" value="true" />
             </manifest>

after
Code:

<delete file="@{jar}" failonerror="false" />

You need this to run older EC version under Java 7u51+.

Regards,
Joachim

Hi,

thanks Joachim, thanks for your add-on-info!

For all "other" readers: please note, you need this extra-ant-statement in two situations:

1. you sign old CaptainCasa client libraries. The manifest files of CaptainCasa client libraries already contain the adequate manifest-file information.

2. you sign own client libraries.

Regards, Björn

Hi @all,

I recognized that in the eclnt manifest, the attributes

Code:

<attribute name="Trusted-Only" value="true" />
 <attribute name="Trusted-Library" value="true" />

are missing. When I set the those in our own client library (client extensions), but they are not set in the "parent" JAR, you will get errors like the attached one. Note that the default CC class org/eclnt/client/elements/PageElement is not found, as well as our own (Stacktrace says org.eclnt.client.elements.impl.DOWNLOADDOKUMENTElement, but it'n in the package eclntextensions really...).
Please also note the wrong log line "Loading the component from package ecntextensions failed as well", this typo cost us some time. ;-)

Well after all, (read this as 'after I removed the two attributes from our own JAR'), it now seems to work.

Question is, in my opinion, whether the CC library should, as a default, ship with the Trusted-* attributes..? I don't exactly know if this could break other usage scenarios. Do you know more?

I am now thinking about overwriting/extending the default eclnt manifest. Until now I reused when resigning. What do you think?

BR

Hi Sebastian,

first: the typo is corrected - sorry...

In general there is no problem if you update the manifest files as part of your deploymenet. Please do not hesitate to do so.

Well, changing these manifest attributes as part of the default delivery: I believe the same problem that you currently have when mixing "trusted-only=true" and "trusted-only not set" jars should then come up in other scenarios. So, I am a bit sceptical to just do it.

Are there any advantages when setting these parameters, e.g. a lower number of security popups when starting the applet/webstart?

Regards, Björn

PS: this is no response but my comment into the discussion, @all: please add your coments...!

Hi,

I think in general it is a good idea to use the Trusted-* attributes in the manifest:

Code:

The Trusted-Only attribute is used to prevent untrusted classes or resources from being loaded for an applet or application. Set the value of the attribute to true, for example:
 
 Trusted-Only: true
 This attribute prevents a privileged application or applet from being repurposed with untrusted components. All classes and resources in the application or applet must be signed and request all permissions.

So there are security advantages, though they might be of more a theoretical nature.. But you can never know when the JRE behavior is changed and the attributes are important. So at least thinking about the implications is an important step.
And yes, I also think that defaulting to Trusted-Only in CC can have implications in other deployments. :-/

Now back to techi stuff ;-)
Have a look at the Spec (JAR File Manifest Attributes for Security). It explains why the class could not be found: A different classloader is used for the "trusted" JAR's classes, so using Class.forName() for example can be faulty. I think changing some code might overcome implications of using the Trusted-* attributes. But I haven't checked the client's sources.

So for now everything is okay and this thread is kind of a sticky note for everyone who has to sign some JARs:

Resign eclnt.jar to use the above posted example manifest or leave the Trusted-* attributes in you own JAR.

BR