On 2018-04-12 13:08:57 [+0000], Nicola Tuveri wrote: > Package: openssl > Version: 1.0.2l-1~bpo8+1 > Severity: important > Tags: patch
backports? > Dear Maintainer, > > I'm developing an ENGINE for OpenSSL, and close to release, I noticed > that in Ubuntu and in Debian the build fails with the following output: > > ``` > /usr/bin/cc -fPIC -g -shared -Wl,-soname,liblibsuola.so -o liblibsuola.so > CMakeFiles/suola.dir/suola.c.o CMakeFiles/suola.dir/suola_keypair.c.o > CMakeFiles/suola.dir/debug/debug.c.o > CMakeFiles/suola.dir/meths/X25519_meth.c.o > CMakeFiles/suola.dir/meths/ed25519_meth.c.o > CMakeFiles/suola.dir/meths/suola_asn1_meth.c.o > CMakeFiles/suola.dir/meths/suola_md_identity_meth.c.o > CMakeFiles/suola.dir/ossl/ossl_compat.c.o > CMakeFiles/suola.dir/ossl/suola_err.c.o > CMakeFiles/suola.dir/ossl/suola_objects.c.o > CMakeFiles/suola.dir/providers/libsodium/base.c.o > CMakeFiles/suola.dir/providers/libsodium/curve25519.c.o > CMakeFiles/suola.dir/providers/libsodium/ed25519.c.o -lssl -lcrypto > /opt/libsodium-stable/lib/libsodium.so -Wl,-z,defs > -Wl,-rpath,/opt/libsodium-stable/lib: > CMakeFiles/suola.dir/meths/suola_asn1_meth.c.o: In function > `suola_register_asn1_meth': > /usr/local/src/libsuola/meths/suola_asn1_meth.c:505: undefined reference to > `EVP_PKEY_asn1_set_item' > collect2: error: ld returned 1 exit status > make[2]: *** [liblibsuola.so] Error 1 > CMakeFiles/suola.dir/build.make:412: recipe for target 'liblibsuola.so' failed > make[2]: Leaving directory '/usr/local/src/libsuola/build' > make[1]: *** [CMakeFiles/suola.dir/all] Error 2 > make: *** [all] Error 2 > ``` > > This does not happen linking against the same exact release of openssl > compiled from source on the same system. > > I then learned that one of the patches applied by Debian (and included > by derived distributions) has the goal of versioning library symbols to > avoid conflicts. > > Unfortunately said patch is not updated regularly with each release of > OpenSSL, resulting, like in my case, in symbols available in the public > header files but masked through versioning in the shared library binary. > > The attached patch fixes my need by adding `EVP_PKEY_asn1_set_item` to > the list, but you might consider an internal review of your release > process to make sure that the list of symbols is updated whenever a new > upstream releases makes new functions publicly available. > > > I marked this bug as important, as it stops everyone using official > debian packages from using third-party ENGINEs that require to use that > function to set special handling of ASN.1 format, which basically > includes every ENGINE that would add support for cryptosystems that > upstream OpenSSL does not support (defying the purpose of using some > ENGINEs). Not everyone. It should work in stable, doesn't it? > This covers my use case, but basically the package as is results > unusable to any user of any application that may require functions > available in the public headers but accidentally masked in the symbol > versioning step. > > > The ideal outcome of fixing this issue would consist in making the > versioning patch dynamic, checking when symbols are added (or removed) > in newer releases and updating the list accordingly. > > The same versioning patch is applied in the other releases, so it's > worth tagging this bug also for those to make the handling of the > exposed symbols consistent. I'm not yet sure what we should do about this. Sebastian
