Dependencies handling

[tsiakmaki]

After your upgrade, you use itext 5.5.13
https://github.com/keensoft/alfresco-esign-cert/blob/master/esign-cert-repo/pom.xml#L62
where bcprov-jdk15on 1.49 and bcpkix-jdk15on are optional.
For some signatures, these new versions seem to be critical, as they contain fixes for timestamp and certificate parsing.

In our installation, we list:
tomcat/webapps/alfresco/WEB-INF/lib/itextpdf-5.0.6.jar
tomcat/webapps/alfresco/WEB-INF/lib/itextpdf-5.5.10.jar
tomcat/webapps/alfresco/WEB-INF/lib/bcmail-jdk14-1.38.jar
tomcat/webapps/alfresco/WEB-INF/lib/bcmail-jdk15-1.46.jar
tomcat/webapps/alfresco/WEB-INF/lib/bcprov-jdk14-1.38.jar
tomcat/webapps/alfresco/WEB-INF/lib/bcprov-jdk15-1.46.jar
tomcat/webapps/alfresco/WEB-INF/lib/bctsp-jdk14-1.38.jar

(I guess the latest versions are being used. )

Now, I whould like to use 5.5.13 and bcprov, bcpkix 1.49, not bctsp and bcmail.
How should I handle this mess?

[angelborroy-ks]

What Alfresco version are you using?

[tsiakmaki]

Alfresco Platform: 5.2.g

[angelborroy-ks]

Alfresco 5.2.g includes by default:

• bcmail-jdk15-1.46.jar
• bcprov-jdk15-1.46.jar

iText 5.5.13 (https://mvnrepository.com/artifact/com.itextpdf/itextpdf/5.5.13) depends on:

• bcprov-jdk15on 1.49
• bcpkix-jdk15on 1.49

Probably the better approach is to clean up all your LIB folder, and keep only Alfresco libs and iText 5.5.13 dependencies:

• tomcat/webapps/alfresco/WEB-INF/lib/itextpdf-5.5.13.pdf
• tomcat/webapps/alfresco/WEB-INF/lib/bcprov-jdk15on-1.49.jar
• tomcat/webapps/alfresco/WEB-INF/lib/bcpkix-jdk15on-1.49.jar
• tomcat/webapps/alfresco/WEB-INF/lib/bcmail-jdk15-1.46.jar
• tomcat/webapps/alfresco/WEB-INF/lib/bcprov-jdk15-146.jar

[tsiakmaki]

The issue here is that if I keep all the versions, i am getting error:

java.lang.SecurityException: class "org.bouncycastle.asn1.ASN1Primitive"'s signer information does not match signer information of other classes in the same package
        at java.lang.ClassLoader.checkCerts(ClassLoader.java:898)
        at java.lang.ClassLoader.preDefineClass(ClassLoader.java:668)
        at java.lang.ClassLoader.defineClass(ClassLoader.java:761)
        at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
        at org.apache.catalina.loader.WebappClassLoaderBase.findClassInternal(WebappClassLoaderBase.java:3205)
        at org.apache.catalina.loader.WebappClassLoaderBase.findClass(WebappClassLoaderBase.java:1373)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1861)
        at org.apache.catalina.loader.WebappClassLoaderBase.loadClass(WebappClassLoaderBase.java:1735)
        at com.itextpdf.text.pdf.AcroFields.verifySignature(AcroFields.java:2425)
        at com.itextpdf.text.pdf.AcroFields.verifySignature(AcroFields.java:2373)
        at es.keensoft.alfresco.behaviour.CustomBehaviour.getDigitalSignatures(CustomBehaviour.java:312)
       ...

When I manually delete bcmail-jdk15-1.46.jar, bcprov-jdk15-146.jar, and restart, it works.

[tsiakmaki]

I have (desperately) updated the pom.xml, to include fake resources of 1.46:

<build>
                <finalName>${project.artifactId}-${project.version}</finalName>
		<resources>
			<resource>
				<directory>${project.basedir}/src/main/resources/libs</directory>
				<includes>
					<!-- bcpkix-jdk15on renamed to override alfresco lib -->
					<include>bcprov-jdk15-1.46.jar</include>
					<!-- bcpkix-jdk15on renamed to override alfresco lib -->
					<include>bcmail-jdk15-1.46.jar</include>
				</includes>
				<filtering>false</filtering>
				<targetPath>${app.amp.output.folder}/lib</targetPath>
			</resource>

How bad is this?

bouncycastle usage seems to be only at:
https://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/repository/source/java/org/alfresco/repo/security/authentication/MD4PasswordEncoderImpl.java
https://svn.alfresco.com/repos/alfresco-open-mirror/alfresco/HEAD/root/projects/repository/source/java/org/alfresco/filesys/config/ServerConfigurationBean.java

[angelborroy-ks]

I'm not sure about the problem... Are you using AMP packaging?
Why don't include them as Maven dependencies?

[tsiakmaki]

cause maven will bring the real 1.46 jars.
I have renamed the 1.49 jar to 1.46 (could have used empty jar files as well), and on deploy the alfresco's 1.46 jars are overidden.

The exceptions shows that the 1.46 jars are used when both 1.46 and 1.49 exists.