Open SergejIsbrecht opened 1 year ago
Two objects of the class sun.security.x509.X509CertImpl
are referenced by the ImageCodeInfo.frameInfoObjectConstants
object array, which is referenced by com.oracle.svm.core.code.ImageCodeInfo.prepareCodeInfo()
.
The two X509CertImpl
objects are returned from org.conscrypt.NativeCryptoJni.class.getSigners()
and included (indirectly, after some processing) in the com.oracle.svm.core.code.ImageCodeInfo.frameInfoObjectConstants
array by the method com.oracle.svm.hosted.reflect.ReflectionMetadataEncoderImpl.addClassMetadata()
.
The archive conscrypt-openjdk-uber-2.5.2.jar
holds a META-INFO/MANIFEST.MF
containing:
Name: org/conscrypt/NativeCryptoJni.class
SHA-256-Digest: ly/K0/AVLxNxmFXMLYhNeWEQeBzs0fzPLsZnDS45G1E=
And the archive also contains the two X.509 certificates, loaded into the two X509CertImpl
objects, in the file META-INFO/SIGNINGC.RSA
.
@loicottet, I believe the changes relative to this new behavior were introduced in this commit. Do you think this new behavior introduced a regression?
This commit introduced reflective access to signers in Native Image, so it is possible that the issue comes from here. What looks strange to me is that there are no signers registered in the reflect-config.json
file of the reproducer. I will look into it.
I have the same issue with Bouncy Castle when using GraalVM CE 17.0.7+7.1
@loicottet, did you make any progress on this? It seems other place on the internet have the same issue (quick google search). I tried it with the latest / greatest Oracle GraalVM and the issue still persists.
Just FYI, if I were to remove the signer
entries from the META-INF/MANIFEST.MF, the generation is successful with 23.0 as well.
META-INF/MANIFEST.MF
Name: org/conscrypt/ConscryptCertStore.class
SHA-256-Digest: IvVp23Y7HX5EpUpQhoh/EE90eBKFQlTMDsbZVzaYW/4=
Name: org/conscrypt/OpenSSLMac$HmacSHA1.class
SHA-256-Digest: oH6h4N4UU08DQ0cxffN1fddLZXb46QWe4FR+FqEDzZY=
...
META-INF/MANIFEST.MF
Manifest-Version: 1.0
Implementation-Title: conscrypt-openjdk-uber
Automatic-Module-Name: org.conscrypt
Target-Compatibility: 1.7
Bundle-SymbolicName: org.conscrypt
Implementation-Version: 2.5.2
BoringSSL-Version: 49f0329110a1d93a5febc2bceceedc655d995420
Built-By: root
Bnd-LastModified: 1617109637399
Bundle-ManifestVersion: 2
Import-Package: javax.crypto,javax.crypto.spec,javax.net,javax.net.ssl
,javax.security.auth.x500,javax.security.cert,org.conscrypt,org.consc
rypt.ct,org.conscrypt.io,sun.security.x509
Require-Capability: osgi.ee;filter:="(&(osgi.ee=JavaSE)(version=1.7))"
Built-JDK: 1.8.0_131
Tool: Bnd-4.3.0.201909301554
Export-Package: org.conscrypt;uses:="javax.crypto,javax.net.ssl,javax.
security.auth.x500,org.conscrypt.ct";version="2.5.2",org.conscrypt.ct
;uses:="org.conscrypt";version="2.5.2",org.conscrypt.io;version="2.5.
2"
Bundle-Name: org.conscrypt
Bundle-Version: 2.5.2
Source-Compatibility: 1.7
Created-By: 1.8.0_131 (Oracle Corporation)
and remove /META-INF/SIGNINGC.SF
and SIGNINGC.RSA
repackage with
jar cmf META-INF/MANIFEST.MF ../edited.conscrypt.jar *
Not sure if my issue is related. I want to use the native-image.cmd
to compile a project but I keep getting:
> com.oracle.svm.core.util.VMError$HostedError: com.oracle.graal.pointsto.util.AnalysisError$TypeNotFoundError: Type not found during analysis: HotSpotType<Lsun/security/x509/X509CertImpl;, resolved>
Of course I tried looking around files that could have this dependency, but no dice. I tried both 21.0.1 and 17.0.9 but no luck.
This is caused by the fact that signers are mistakenly included in the image even if they are not registered as reflectively accessible, as well as the fact that signer classes are not correctly registered during analysis when they are. I have a fix on the way for these issues.
@loicottet ,
would it be possible to backport it to 23.x?
Yes, we can do that
Describe the issue Trying to build a native-image with conscrypt (https://github.com/google/conscrypt) included.
Steps to reproduce the issue
README.md
instructions in RepoDescribe GraalVM and your environment:
More details
Using following settings (see repository example) will result in an Error when generating an native-image with GraalVM CE native-image 23.0. With GraalVM CE 22.3.x the generation of the native-image succeeds without any issue.
Is there any guidance what I should do in such cases?