libengine-pkcs11-openssl installs to wrong directory

Bug #1690287 reported by Luke Faraone on 2017-05-12
This bug affects 1 person
Affects Status Importance Assigned to Milestone
engine-pkcs11 (Ubuntu)
Luke Faraone
libp11 (Debian)
Fix Released
libp11 (Ubuntu)
Luke Faraone

Bug Description

With both libengine-pkcs11-openssl and openssl installed:

$ openssl engine pkcs11
139951744663256:error:25066067:DSO support routines:DLFCN_LOAD:could not load the shared library:dso_dlfcn.c:187:filename(/usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/ /usr/lib/x86_64-linux-gnu/openssl-1.0.0/engines/ cannot open shared object file: No such file or directory
139951744663256:error:25070067:DSO support routines:DSO_load:could not load the shared library:dso_lib.c:233:
139951744663256:error:260B6084:engine routines:DYNAMIC_LOAD:dso not found:eng_dyn.c:467:
139951744663256:error:2606A074:engine routines:ENGINE_by_id:no such engine:eng_list.c:390:id=pkcs11

$ dpkg -L libssl1.0.0 | grep engine | head -n 1
$ dpkg -L libengine-pkcs11-openssl | grep engine | head -n 1

ProblemType: Bug
DistroRelease: Ubuntu 17.04
Package: libengine-pkcs11-openssl 0.4.4-1
ProcVersionSignature: Ubuntu 4.10.0-20.22-generic 4.10.8
Uname: Linux 4.10.0-20-generic x86_64
ApportVersion: 2.20.4-0ubuntu4
Architecture: amd64
CurrentDesktop: Unity:Unity7
Date: Thu May 11 20:04:09 2017
InstallationDate: Installed on 2017-04-09 (32 days ago)
InstallationMedia: Ubuntu 17.04 "Zesty Zapus" - Beta amd64 (20170321)
SourcePackage: libp11
UpgradeStatus: No upgrade log present (probably fresh install)

Luke Faraone (lfaraone) wrote :
Changed in libp11 (Debian):
status: Unknown → New

Thanks Luke for making us aware!

Note/TL;DR: this is openssl 1.0/1.1 fallout, the Debian bug has much more history one it already and Luke is proposing a fix there which we should pick up into 17.04 then as well.

I could confirm this affecting all releases back to trusty which makes me wonder if I'm doing something wrong as I'm certainly no pkcs expert :-/
Need to be revisited once Debian acks on the fix - but to me atm it seems this never worked?! which makes it lower prio than it seems at first.

Older releases had that at least in a non version specific path, so with some hackery one could load it:

openssl engine dynamic -pre SO_PATH:/usr/lib/engines/ -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre

On Artful that verion-free path is no more, but you can still go with a workaround like:
openssl engine dynamic -pre SO_PATH:/usr/lib/x86_64-linux-gnu/openssl-1.0.2/engines/ -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD -pre

Which all does not mean it should not be fixed, I just wondered if that can be loaded at all.

Luke you assigned the Ubuntu portion to yourself - will you be driving this on the Ubuntu side as well?

Luke Faraone (lfaraone) wrote :

> Luke you assigned the Ubuntu portion to yourself - will you be driving this on the Ubuntu side as > well?

I'll need a sponsor (I'm in ~moto, not ~core-dev), but happy to.

Luke Faraone (lfaraone) wrote :

Source package was different in 16.04

Changed in engine-pkcs11 (Ubuntu):
milestone: none → xenial-updates
Luke Faraone (lfaraone) wrote :

I think there was a *brief* period where this worked correctly in the archive, insofar as the version of ``libengine-pkcs11-openssl`` in Yakkety, built against xenial libssl1.0.0, would've used the right path.

But you are right that this does not appear to ever actually worked in a stable Ubuntu release. I haven't checked lucid, though ;)

Luke Faraone (lfaraone) wrote :
Luke Faraone (lfaraone) wrote :
Changed in engine-pkcs11 (Ubuntu):
status: New → Triaged
assignee: nobody → Luke Faraone (lfaraone)
tags: added: patch
Changed in libp11 (Debian):
status: New → Fix Committed
Changed in libp11 (Debian):
status: Fix Committed → Fix Released
tags: added: server-next

I checked if I could help sponsoring that already - thanks Luke for all the work!
For engine-pkcs11 one has to realize that it was dropped in artful as it seems.
In that sense for he SRU "it is released" I'd think - at least when the other packages change are complete.

For libp11 it is clearer - but the fix for libp11 in Debian is still in experimental, I guess this might only resolve after the stretch release? Then it will be auto-synced into artful with the fix.
=> From there we have to check SRU'ability (issue is present back to Trusty)

@Luke - please let me know if I got that somehow wrong - or anything else than waiting the few days for Debian to act on and release that fix has to be done atm.

tags: removed: server-next

Coming by checking bugs that were dormant an unexpected long time.

@Luke: Before doing anything wrong here I wanted to ask on an update of the latest status and next steps in your opinion?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.