Bug 1444994 - pkcs11-helper; (RFE) build using compat-openssl10 (instead of openssl-1.1.x)
Summary: pkcs11-helper; (RFE) build using compat-openssl10 (instead of openssl-1.1.x)
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: pkcs11-helper
Version: 26
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Kalev Lember
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1445349
Blocks: 1391544 1423077 1432152 1440468
TreeView+ depends on / blocked
 
Reported: 2017-04-24 17:15 UTC by Rex Dieter
Modified: 2017-04-28 12:49 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-04-25 12:29:37 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Rex Dieter 2017-04-24 17:15:37 UTC
At least 2 fedora pkgs that use pkcs11-helper do not (or can not) yet support openssl-1.1.x:
openvpn
qca

and only 1 that does (according to repoquery):
ecryptfs-utils

Given this, please consider building pkcs11-helper against compat-openssl10 instead

Comment 1 Rex Dieter 2017-04-24 17:19:09 UTC
for qca case, see also bug #1423077

I couldn't find a bug for documenting openvpn issue other than it's changelog:

* Thu Feb 09 2017 Jon Ciesla <limburgher> 2.4.0-2
- Move to mbedtls to resolve FTBFS.
- Dropped, re-add once openvpn supports openssl 1.1.x
-    --enable-pkcs11 \
-    --enable-x509-alt-username \

Comment 2 Rex Dieter 2017-04-24 17:23:05 UTC
ah, found openvpn bug #1391544

Comment 3 Rex Dieter 2017-04-24 17:26:45 UTC
also related openvpn bug #1432152

Comment 4 David Sommerseth 2017-04-24 17:33:13 UTC
Please also see comment in bug #1440468 comment #10

Comment 5 Nikos Mavrogiannopoulos 2017-04-25 09:27:22 UTC
Please do not do that. Add a compat package for pkcs11-helper.

Comment 6 Rex Dieter 2017-04-25 11:55:59 UTC
Can you explain why that is a better plan (If most pkcs11-helpder consumers in the distro cannot use it as-is)?

Comment 7 Nikos Mavrogiannopoulos 2017-04-25 12:27:31 UTC
(In reply to Rex Dieter from comment #6)
> Can you explain why that is a better plan (If most pkcs11-helpder consumers
> in the distro cannot use it as-is)?

Because we are not staying with openssl 1.0.2, we are moving to openssl 1.1.0. pkcs11-helper is a library intended for openssl applications and thus should not be transformed to a compat library as it will prevent applications from moving to the new openssl. 

If you want to keep the pkcs11 functionality to the applications which didn't move to the new openssl please introduce a compat-openssl102-pkcs11-helper library which these applications can use. This is the approach used for all other libraries depending on openssl, there is no reason for an exception here.

Comment 8 Rex Dieter 2017-04-25 13:00:37 UTC
That doesn't explain why, but ok, if you want to be a bit stubborn about not serving the needs of a majority of the existing pkcs11-helper consumers in the distro... that's your (unfortunate) choice... I guess.

Can you give another example of other libraries depending on compat-openssl10 also providing compat libraries?  I'm not aware of any.

Comment 9 Rex Dieter 2017-04-25 13:04:51 UTC
An irony of your suggested approach is that compat-openssl10-pkcs11-helper will get used more than pkcs11-helper.  I assume you're a pkcs11-helper package maintainer... would you be able/interested in helping maintain a compat- pkg ?

Comment 10 Nikos Mavrogiannopoulos 2017-04-25 13:39:31 UTC
There is no irony in that, it is simply a reality. Yes, it will be used more initially, but at some point either these programs will be dropped from fedora or they will move to openssl 1.1.0.

See the approach followed for libp11.
https://bugzilla.redhat.com/show_bug.cgi?id=1389202

Comment 11 Rex Dieter 2017-04-25 14:02:00 UTC
turns out it wasn't too hard, just take existing pkg and bump soname, review @ bug #1445349 , and I'll take the liberty of moving all the blocker bugs there.

(that said, I still urge you to consider that it's not good practice to move to an incompatible version of a library before a majority of it's dependencies are ready for the change)

Comment 12 David Sommerseth 2017-04-25 20:13:47 UTC
It is absolutely challenging when there are big updates which breaks APIs and requires a lot of things to move forward.  But I do actually agree to the process.  This is the only way to really get things moving forward.

If Fedora would stay on OpenSSL 1.0 until all its users (or the majority) is ready, then I think that would hold Fedora back far longer - and the upstream projects would not have the same incentives to move forward as well.  And we would be in the exact same position when Fedora is forced to retract openssl-1.0.x completely due to upstream OpenSSL stopping to support those versions completely.

That said, with the dependency chains involved this does indeed get more complicated (which OpenVPN have noticed).  But OpenVPN is moving forward on the OpenSSL 1.1 support.  Mostly leaving qca and probably a few other handfuls needing the compat-openssl10 chain.  I hope this will be resolved within a couple of months actually.

So, to be honest, I think it is far better to put the efforts into moving upstream projects towards OpenSSL 1.1 support than to band-aid with compat-* packages.  Such band-aid is only truly useful as a workaround when upstream projects to not move forward and the package is truly required/critical in Fedora.  And I see no real reasons why upstream projects would not move towards OpenSSL v1.1.

Comment 13 Rex Dieter 2017-04-26 12:33:46 UTC
No one is saying continued efforts to port things to openssl-1.1.x is bad.  That's most definitely a "good thing(tm)".

I'm just... surprised that the pkcs11-helper maintainer chose to move on to support openssl-1.1 without making any (obvious) effort to ensure current consumers still work and aren't broken. :(  When the problem was highlighted, chose what I perceived as a largely unhelpful move: "WONTFIX" on this bug (and "fix it yourself with a compat pkg" comment).  Ideally, I'd hoped pkcs11-maintainer(s) would actively help with the transition.  (They still can... hint hint, by helping review the linked compat-openssl10-pkcs11-helper and/or offer to co-maintain it)


In case it wasn't obvious, my primary interest is around Qt5.  Qt is (imho) fairly important, and qca is a major crypto addon used widely in Qt-based projects. So I think it not unfair to say this falls in "the package is truly required/critical in fedora" characterization.  It's own time frame for openssl-1.1 support is still somewhere 3-12 months away (Qt-5.10 at the earliest)

Comment 14 Nikos Mavrogiannopoulos 2017-04-26 14:15:17 UTC
(In reply to Rex Dieter from comment #13)
> No one is saying continued efforts to port things to openssl-1.1.x is bad. 
> That's most definitely a "good thing(tm)".
> 
> I'm just... surprised that the pkcs11-helper maintainer chose to move on to
> support openssl-1.1 without making any (obvious) effort to ensure current
> consumers still work and aren't broken. :(  When the problem was
> highlighted, chose what I perceived as a largely unhelpful move: "WONTFIX"
> on this bug (and "fix it yourself with a compat pkg" comment).  Ideally, I'd
> hoped pkcs11-maintainer(s) would actively help with the transition.  (They
> still can... hint hint, by helping review the linked
> compat-openssl10-pkcs11-helper and/or offer to co-maintain it)

Hi Rex, sorry if I sounded harsh. The package has no real active maintainer unfortunately. I'm maintaining out of necessity to make it consistent with out PKCS#11 move in Fedora [0]. I do not have the resources to co-maintain it. If no-one beats me to it, I'll try to review it the upcoming weeks (my availability is very limited sorry).

[0]. https://fedoraproject.org/wiki/PackagingDrafts/Pkcs11Support

Comment 15 David Woodhouse 2017-04-28 09:56:55 UTC
We should migrate OpenVPN to libp11.

Comment 16 David Sommerseth 2017-04-28 12:49:24 UTC
(In reply to David Woodhouse from comment #15)
> We should migrate OpenVPN to libp11.

Completely agree!  And "we" will do that when "we" get some available time to do so.  In the mean time, patches are welcome ;-)


Note You need to log in before you can comment on or make changes to this bug.