Closed spacekitteh closed 7 years ago
Conscrypt only works with BoringSSL. When we make a release, we will note the BoringSSL commit-ish that Conscrypt works with.
I know. So why does AOSP pull in OpenSSL when building conscrypt instead of BoringSSL?
On Wed, 28 Dec 2016 at 02:34 Kenny Root notifications@github.com wrote:
Closed #20 https://github.com/google/conscrypt/issues/20.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/conscrypt/issues/20#event-905841505, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2crF3azRQSs0r5KCwwWmnqUdP_w0kKks5rMT4QgaJpZM4LWCIh .
Maybe you have changed your manifest with a local_manifests
entry. It definitely uses BoringSSL.
Nope, I haven't. I know it should be using BoringSSL, but somehow the build seems to be prioritising OpenSSL over BoringSSL.
On Wed, 28 Dec 2016 at 15:13 Kenny Root notifications@github.com wrote:
Maybe you have changed your manifest with a local_manifests entry. It definitely uses BoringSSL https://android.googlesource.com/platform/manifest/+/master/default.xml#94 .
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/google/conscrypt/issues/20#issuecomment-269427060, or mute the thread https://github.com/notifications/unsubscribe-auth/AB2crBsy5_sKtykHaOLQ7yAJOYs6V3Vuks5rMfARgaJpZM4LWCIh .
Maybe it's picking up your host libcrypto
somehow. The rule to build for use with signapk specifically uses libcrypto_static
and libssl_static-host
to try to avoid this name conflict.
This is a conversation is more suited for a mailing list than an issue tracker, though.
how could it possibly be the case? Is there any way I can see what it's loading?
So I used jdb to check if org.conscrypt.NativeCrypto.isBoringSSL was true. It was indeed true - and yet get_cipher_names somehow uses OpenSSL.
main[1] eval org.conscrypt.NativeCrypto.isBoringSSL
org.conscrypt.NativeCrypto.isBoringSSL = true
main[1] run
>
Exception occurred: java.lang.ExceptionInInitializerError (uncaught)"thread=main", com.android.signapk.SignApk.main(),
line=1,175 bci=930
main[1] run
> Exception in thread "main" java.lang.ExceptionInInitializerError
at org.conscrypt.OpenSSLBIOInputStream.<init>(OpenSSLBIOInputStream.java:34)
at org.conscrypt.OpenSSLX509Certificate.fromX509PemInputStream(OpenSSLX509Certificate.java:119)
at org.conscrypt.OpenSSLX509CertificateFactory$1.fromX509PemInputStream(OpenSSLX509CertificateFactory.java:220
)
at org.conscrypt.OpenSSLX509CertificateFactory$1.fromX509PemInputStream(OpenSSLX509CertificateFactory.java:216
)
at org.conscrypt.OpenSSLX509CertificateFactory$Parser.generateItem(OpenSSLX509CertificateFactory.java:94)
at org.conscrypt.OpenSSLX509CertificateFactory.engineGenerateCertificate(OpenSSLX509CertificateFactory.java:27
2)
at java.security.cert.CertificateFactory.generateCertificate(CertificateFactory.java:339)
at com.android.signapk.SignApk.readPublicKey(SignApk.java:182)
at com.android.signapk.SignApk.main(SignApk.java:1087)
Caused by: java.lang.IllegalArgumentException: Unknown cipher suite supported by native code: DH-DSS-AES256-GCM-SHA384
at org.conscrypt.NativeCrypto.<clinit>(NativeCrypto.java:750)
... 9 more
The application exited
[1]+ Exit 1 java -Xrunjdwp:transport=dt_socket,server=y,suspend=y,address=9999 -Xdebug -Djava.librar
y.path=out/host/linux-x86/lib64 -jar out/host/linux-x86/framework/signapk.jar --min-sdk-version 25 build/target/produc
t/security/testkey.x509.pem build/target/product/security/testkey.pk8 out/target/product/marlin/obj/APPS/BasicDreams_i
ntermediates/package.apk.unsigned out/target/product/marlin/obj/APPS/BasicDreams_intermediates/package.apk.signed
ah, it's a result of nixos fucking with the procedure linkage table!
after looking around with gdb, I got to this point:
> │10749 Unique_SSL_CTX sslCtx(SSL_CTX_new(SSLv23_method()));
│
│10750 Unique_SSL ssl(SSL_new(sslCtx.get()));
which in assembly is
>│0x3ffcd67fd50 <NativeCrypto_get_cipher_names(_JNIEnv*, _jclass*, _jstring*)+64> callq 0x3ffcd669060 <SSLv23_method@plt>
the debugging info says that it points to the one included in libconscrypt_openjdk_jni.so, but nixos modifies ELFs to take into account the different directory layout.
so it presumably scans the ELF for symbols and then fails to recognise the various BoringSSL functions are statically linked, and rewrites their addresses to point to OpenSSL's methods.
conscrypt fails while building AOSP under NixOS.
OS: NixOS AOSP version: Copperhead 7.1.1r6 aosp_marlin OpenJDK versions tried: 112b15, 122b3 Installed OpenSSL versions tried: OpenSSL 1.0.2j, OpenSSL 1.1.0, LibreSSL 2.5.0 make showcommands -j4