search

keensoft / alfresco-esign-cert

Alfresco client certificate signature (including Chrome)
Other
28 stars 30 forks source link

Dependencies handling #48

Open tsiakmaki opened 5 years ago

tsiakmaki commented 5 years ago

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 commented 5 years ago

What Alfresco version are you using?

tsiakmaki commented 5 years ago

Alfresco Platform: 5.2.g

angelborroy-ks commented 5 years ago

Alfresco 5.2.g includes by default:

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

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

tsiakmaki commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

tsiakmaki commented 5 years ago

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.