Bug 1448649

I cannot reproduce this because I do not have a DNIe card. However, I do not think it is feasible to:

* Replace boringssl with OpenSSL
* Link _just_ boringssl statically into Chromium
* Link _every_ component statically into Chromium

Additionally, there is nothing in the Debian thread which talks about this issue at all, I do not think it is related.

I'm working on a major release update for Chromium, perhaps that will fix this bug for you.

Hi,

Yes, I know you weren't going to reproduce it (you need a card). I'm going to try to explain in a different way.

The boringssl has the same method X509_verify than the openssl library:

nm /usr/lib64/chromium-browser/libboringssl.so | grep X509_verify
00000000000afaa0 T X509_verify
00000000000aaf80 T X509_verify_cert
00000000000a9b30 T X509_verify_cert_error_string

So, when the opensc tries to use the same method X509_verify, the one in libboringssl is used and not the one in openssl (libcrypto.so).

ldd /usr/lib64/libopensc.so.4
	linux-vdso.so.1 (0x00007fff3f7dc000)
	libcrypto.so.10 => /lib64/libcrypto.so.10 (0x00007f9515d5f000)
	...


In debian the libboringssl.so doesn't exist, it is just inside the binary and not exposed to the rest (this nm is done over the symbols in the package chromium-dbg_57.0.2987.98-1~deb8u1_amd64.deb in debian):

nm 06e3acde7124fca936e2a5b2fed8196cc5fb46.debug | grep X509_verify
00000000027cca20 t X509_verify
00000000027c8c30 t X509_verify_cert

So, the difference is that in debian is t (local) and in fedora is T (external). And the opensc uses the one in libboring.so instead the one in libcrypto.so. I don't know if it was on purpose in debian, but in debian you finally use the openssl library.

Thanks!

Okay. I understand what you're saying here. What I _do not_ understand is why libopensc.so.4 is resolving X509_verify with /usr/lib64/chromium-browser/libboringssl.so.

On Fedora 26:

[spot@localhost sandbox]$ readelf -d /usr/lib64/libopensc.so.4

Dynamic section at offset 0x1a0ea0 contains 28 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libcrypto.so.1.1]
 0x0000000000000001 (NEEDED)             Shared library: [libz.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000000e (SONAME)             Library soname: [libopensc.so.4]

[spot@localhost sandbox]$ ldd /usr/lib64/libopensc.so.4
	linux-vdso.so.1 (0x00007ffd0adb5000)
	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007fa4c4e80000)
	libz.so.1 => /lib64/libz.so.1 (0x00007fa4c4c69000)
	libdl.so.2 => /lib64/libdl.so.2 (0x00007fa4c4a65000)
	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fa4c4847000)
	libc.so.6 => /lib64/libc.so.6 (0x00007fa4c4476000)
	/lib64/ld-linux-x86-64.so.2 (0x00005577e416f000)

My best guess is that something is happening inside Chromium when OpenSC is used inside the browser environment which is resulting in the symbol confusion.

The problem is that Fedora can't just compile boringssl inside Chromium as static (I tried, it fails), nor can we compile everything static (because that breaks chrome-remote-desktop).

The only other option I can think of would be to rename the functions in boringssl (and all the places they are called in Chromium) to avoid the overlap.

I think you should open this bug with the Chromium upstream and see if they have any advice on how they'd prefer to resolve this issue.

Hi,

Now I understand your point of making libboringssl.so dynamic, it is used by other packages.

I think the reason to fail under chromium is just because the libboringssl.so is already loaded (by chromium) and the symbol is there and external (T). It's the same as using LD_PRELOAD, it's already there. I can indeed emulate the problem using LD_PRELOAD using normal opensc tools:

$ pkcs11-tool -I -l
Cryptoki version 2.20
Manufacturer     OpenSC Project
Library          OpenSC smartcard framework (ver 0.16)
Using slot 0 with a present token (0x0)
Logging in to "PIN1 (DNI electrónico)".
Please enter User PIN: 
$ LD_PRELOAD=/usr/lib64/chromium-browser/libboringssl.so pkcs11-tool -I -l
Cryptoki version 2.20
Manufacturer     OpenSC Project
Library          OpenSC smartcard framework (ver 0.16)
Using slot 0 with a present token (0x0)
Logging in to "PIN1 (DNI electrónico)".
Please enter User PIN: 
Segmentation fault (core dumped)

The funny thing is that with chrome everything works, because google distributes an enormous binary of 118MB with everything linked statically except the basics. So official chrome works fine, it's the same case as debian.

I suppose that I'll need to report a bug against boringssl, but for that I need some files that are inside the card to do a test-case (coding to extract the certificates that make it crash). You know, a real pain in the ass. And then I'm not sure they are going to even care about it.

Thanks anyway!

bug filed against boringssl:

https://bugs.chromium.org/p/boringssl/issues/detail?id=194

I see they didn't like that very much. If you want to try to namespace out the conflict in boringssl, let me know. I'm happy to carry that patch.

I think my issue is done on purpose in boringssl, it's like they are improving the performance, the manageability or something in openssl at the cost of not covering all the features. So opensc is just a collateral damage. You can see what they said, they recommend to link boringssl statically and not expose it to the rest of the system for end-user installations (because of the previous fact). I don't know about the method renaming solution, it seems that chromium devs considered it at the beginning but they finally gave up. I still think the easiest solution here is compiling boringssl statically inside chromium but it's up to you guys.

Thanks!

This message is a reminder that Fedora 25 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 25. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '25'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 25 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Fedora 25 changed to end-of-life (EOL) status on 2017-12-12. Fedora 25 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Reopening, as this remains an issue in Fedora and we now can reproduce it trivially simply with GSSAPI calls (so no special hardware required).

See https://bugzilla.redhat.com/show_bug.cgi?id=1640158

See previous comments. We use is_component_build=true to enable the many (many) libaries inside chromium to be built as shared objects. Fedora can't just compile boringssl inside Chromium as static (I tried, it fails), nor can we compile everything static (because that breaks chrome-remote-desktop and makes it impossible to swap in rpmfusion version to enable codecs).

Upstream does not care about these issues, and just wants us to build everything statically.

Hence, CLOSED->CANTFIX.