Bug 1484449 - Stop shiping libnssckbi.so as part of NSS, use p11-kit-trust.so exclusively
Summary: Stop shiping libnssckbi.so as part of NSS, use p11-kit-trust.so exclusively
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 28
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Daiki Ueno
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On: 1485450
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-08-23 15:30 UTC by Kai Engert (:kaie) (inactive account)
Modified: 2018-11-27 13:54 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-11-27 13:54:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)
patch v1 (3.85 KB, patch)
2017-08-23 15:32 UTC, Kai Engert (:kaie) (inactive account)
no flags Details | Diff

Description Kai Engert (:kaie) (inactive account) 2017-08-23 15:30:13 UTC
I suggest that we stop distributing the NSS module libnssckbi.so.

In past Fedora releases, we have effectively disabled the use of the libnssckbi.so module that is distributed by the NSS library project.

Fedora contains the p11-kit-trust.so module (p11-kit-trust.rpm), which is now an essential system component. It's a binary compatible replacement for libnssckbi.so, made available trough the updates-alternatives system.

Because p11-kit-trust has become an essential system component (and cannot be removed without removing e.g. dnf), the nss/libnssckbi.so module is no longer used by most applications.

NSS should be changed to depend on p11-kit-trust.

This should be a very low risk change, limited to the nss package, and most likely shouldn't affect other applications or packages.

Comment 1 Kai Engert (:kaie) (inactive account) 2017-08-23 15:32:20 UTC
Created attachment 1317144 [details]
patch v1

Comment 2 Kai Engert (:kaie) (inactive account) 2017-08-23 18:20:00 UTC
rawhide fix:
http://pkgs.fedoraproject.org/rpms/nss/c/61169569b13845986b3aeed3cfc3a3012a4427f3?branch=master

Comment 3 Anton Guda 2017-08-25 10:34:28 UTC
mod_nss-1.0.14-5 still requires it, but p11-kit-trust do not
provides it (as seen in header), and not have correct update tool.
It may be better to use in-package symlink, not script?

error: Failed dependencies:
        /usr/lib64/libnssckbi.so is needed by (installed) mod_nss-1.0.14-5.fc27.x86_64

Comment 4 Kai Engert (:kaie) (inactive account) 2017-08-25 15:24:27 UTC
/usr/lib64/libnssckbi.so will continue to exist.

It has been a symlink for several versions already, and points to 
  /etc/alternatives/libnssckbi.so.x86_64

This has already been pointing by default to 
  /usr/lib64/pkcs11/p11-kit-trust.so
and will continue to do so.

The equivalent can be said for the 32-bit version
  /usr/lib/libnssckbi.so
which will be provided by p11-kit-trust.i686

The change requested in this bug is to shop shipping
  /usr/lib/nss/libnssckbi.so
which was an optional, lower priority alternative
(and essentially no longer be used, unless anyone tried to access it directly).

Comment 5 Anton Guda 2017-08-25 16:25:45 UTC
> /usr/lib64/libnssckbi.so will continue to exist
But it not "officialy provided" by the p11-kit-trust.

So, if someone try to update nss, dnf/rpm gives error message:

 Problem: problem with installed package mod_nss-1.0.14-5.fc27.x86_64
  - package mod_nss-1.0.14-5.fc27.x86_64 requires /usr/lib64/libnssckbi.so, but none of the providers can be installed
  - cannot install both nss-3.32.0-3.fc28.x86_64 and nss-3.32.0-2.fc27.x86_64
  - cannot install the best update candidate for package nss-3.32.0-2.fc27.x86_64

error: Failed dependencies:
        /usr/lib64/libnssckbi.so is needed by (installed) mod_nss-1.0.14-5.fc27.x86_64

So, I see 2 way:
0: manualy provide /usr/lib64/libnssckbi.so by p11-kit-trust,
   better with direct symlink.
1: rebuild mod_nss w/o reqirement - if possible.

Comment 6 Kai Engert (:kaie) (inactive account) 2017-08-25 16:41:56 UTC
(In reply to Anton Guda from comment #5)
> > /usr/lib64/libnssckbi.so will continue to exist
> But it not "officialy provided" by the p11-kit-trust.

It's actually officially provided.
The installation scripts of p11-kit install it.

See
http://pkgs.fedoraproject.org/rpms/p11-kit/blob/master/f/p11-kit.spec#_86


> So, if someone try to update nss, dnf/rpm gives error message:
> 
>  Problem: problem with installed package mod_nss-1.0.14-5.fc27.x86_64
>   - package mod_nss-1.0.14-5.fc27.x86_64 requires /usr/lib64/libnssckbi.so,
> but none of the providers can be installed
>   - cannot install both nss-3.32.0-3.fc28.x86_64 and nss-3.32.0-2.fc27.x86_64
>   - cannot install the best update candidate for package
> nss-3.32.0-2.fc27.x86_64

I don't understand how you were able to get into this state, can you please describe what you did?

It seems the error message was shown because you tried to install both fc28 and fc27 packages in parallel?

Here is a f27 scratch build from yesterday:
https://koji.fedoraproject.org/koji/taskinfo?taskID=20725695

Comment 7 Kamil Dudka 2017-08-25 16:54:49 UTC
(In reply to Kai Engert (:kaie) from comment #6)
> It's actually officially provided.
> The installation scripts of p11-kit install it.
> 
> See
> http://pkgs.fedoraproject.org/rpms/p11-kit/blob/master/f/p11-kit.spec#_86

If the file is created in the %post scriptlet, it will exist on the file system but it does not automatically mean that the dependency resolver(s) will see it.

The package that provides it (p11-kit-trust?) either needs to provide a %ghost (the one you have removed from the nss package) or there needs to be an explicit Provides tag.

> I don't understand how you were able to get into this state, can you please
> describe what you did?

I can easily reproduce it on my up2date rawhide VM, too:

% sudo dnf install mod_nss
Last metadata expiration check: 0:02:26 ago on Fri 25 Aug 2017 06:44:42 PM CEST.
Error: 
 Problem: conflicting requests
  - nothing provides /usr/lib64/libnssckbi.so needed by mod_nss-1.0.14-5.fc27.x86_64

Comment 8 Kai Engert (:kaie) (inactive account) 2017-08-25 17:50:05 UTC
Thanks Kamil, that's helpful.

Previously the NSS package had the %ghost entry.
We should update p11-kit to add it.

Comment 9 Kai Engert (:kaie) (inactive account) 2017-08-25 18:36:14 UTC
I've filed 1485450 to handle the dependency regression, a scratch build is running, link in that bug.

Comment 10 Daiki Ueno 2018-06-07 15:28:40 UTC
I see the fix is in rawhide and F28 (in both nss and p11-kit packages), but not in F27.  Kai, do you think we should do that as well in F27 or target F28+ only?

Comment 11 Kai Engert (:kaie) (inactive account) 2018-06-11 18:55:31 UTC
I think it's sufficient to garget F28+ only.

I believe, at the time I had suggested this change, we were already past the change deadline for systemwide f27 changes. Unless there's a good reason to change f27, I'd keep it as is, to avoid surprises.

Comment 12 Rob Crittenden 2018-06-11 19:26:53 UTC
+1 for F28+ only. I may need to tweak mod_nss to handle this as well as it currently symlinks libnssckbi.so to ensure the roots are available.

Comment 14 Ben Cotton 2018-11-27 13:51:11 UTC
This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. 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 '27'.

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 27 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.


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