On 2018-04-12 13:08:57 [+0000], Nicola Tuveri wrote:
> Package: openssl
> Version: 1.0.2l-1~bpo8+1
> Severity: important
> Tags: patch


> 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

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.


Reply via email to