Bug 990434 - package p11-kit-trust.i686 missing
package p11-kit-trust.i686 missing
Status: NEW
Product: Fedora
Classification: Fedora
Component: mash (Show other bugs)
19
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Dennis Gilmore
Fedora Extras Quality Assurance
: Reopened
: 1060764 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-07-31 04:27 EDT by Alphonse Steiner
Modified: 2017-07-26 04:49 EDT (History)
12 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 09:03:15 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
experimental patch v1 (1.21 KB, patch)
2017-07-25 12:56 EDT, Kai Engert (:kaie)
kengert: review? (dueno)
Details | Diff

  None (edit)
Description Alphonse Steiner 2013-07-31 04:27:44 EDT
Description of problem:
The package p11-kit-trust (i686) is not signed, and therefore yum fails to update the p11-kit packages. It is the only p11-kit unsigned package for i686; they are all signed for x86_64.
Comment 1 Stef Walter 2013-07-31 05:02:37 EDT
Bummer. Not sure why that's the case. Reassigning, as the maintainers don't sign our own individual packages.
Comment 2 Kevin Fenzi 2013-08-06 15:40:48 EDT
Can you provide the output and exact version of the package you are seeing?
Comment 3 Alphonse Steiner 2013-08-07 04:15:47 EDT
It was about version 0.18.5-1.fc19.i686 
Now yum cannot even find it. Downloading it directly from download.fedoraproject.org, checking it and... it is signed! 

Well, after dowloading the packages, I can install them. But yum still does not find p11-kit-trust.i686. Even after a 'yum clean all', the output of the command 'yum reinstall p11-kit-trust.i686' is

Installed package p11-kit-trust-0.18.5-1.fc19.i686 (from /p11-kit-trust-0.18.5-1.fc19.i686) not available.
Error: Nothing to do

I have updated the summary. Actually, the problem is that I cannot get this package with yum, even on another machine. Does it work for you, or is it just me?
Comment 4 Kevin Fenzi 2013-08-07 11:23:28 EDT
Are you on a x86_64 install there? 

The 32bit p11-kit-trust is not shipped in the x86_64 repos. At least not currently. 

Why do you need it? 

The "from /p11-kit-trust-0.18.5-1.fc19.i686" also implies that you manually downloaded and installed it, or it would say "from updates" or the like. 

IMHO, you can safely 'yum remove p11-kit-trust-0.18.5-1.fc19.i686'
Comment 5 Stef Walter 2013-08-07 11:26:23 EDT
It's needed for the use of 'Shared System Certificates' in nss.i686

See: https://fedoraproject.org/wiki/Features/SharedSystemCertificates

p11-kit-trust.i686 should be available in x86_64. How can we accomplish this in Fedora?
Comment 6 Alphonse Steiner 2013-08-07 11:52:45 EDT
Yes, it is an x86_64 installation.
After searching through yum history, it was indeed installed manually. I cannot find why it was required, and I cannot remember what required it.

Ok, I have removed it (no dependancies, great!). 
Thank you very much for the help.
You can close this report for my part.
Comment 7 Kevin Fenzi 2013-08-07 12:19:25 EDT
great. Thanks!
Comment 8 Stef Walter 2013-08-07 12:33:07 EDT
It *is* a bug that p11-kit-trust.i686 is not available in Fedora. This will continue to come up.
Comment 9 Kevin Fenzi 2013-08-07 12:34:52 EDT
ok, can you explain why?

Where do you use 32bit nss on 64 bit fedora installs?
Comment 10 Stef Walter 2013-08-07 12:51:58 EDT
(In reply to Kevin Fenzi from comment #9)
> ok, can you explain why?
> 
> Where do you use 32bit nss on 64 bit fedora installs?

Lots of packages depend on either nss.i686 and gnutls.i686. I've put together a rough list below, using repoquery on my x86_64 machine.

As far as an actual use case, I know that 'yum install wine' requires a bunch of the i686 stack, including gnutls.i686. That's just one use case I've personally bumped into.

In order to work with the 'Shared System Certificates' both nss and gnutls (optionally) use p11-kit-trust to provide Certificate Anchor data. It is a module that provides a store of trust data.

The list:

389-admin-0:1.1.31-1.fc19.2.i686
389-adminutil-0:1.1.15-3.fc19.1.i686
389-ds-base-libs-0:1.3.1.2-1.fc19.i686
389-ds-base-libs-0:1.3.1.3-1.fc19.i686
bitlbee-0:3.2-3.fc19.i686
canl-c++-0:1.0.0-2.fc19.i686
connman-0:1.13-1.fc19.i686
coolkey-0:1.1.0-23.fc19.i686
corosynclib-0:2.3.0-3.fc19.i686
corosynclib-0:2.3.1-1.fc19.i686
cups-libs-1:1.6.2-9.fc19.i686
ecryptfs-utils-0:103-2.fc19.i686
evolution-0:3.8.3-2.fc19.i686
evolution-0:3.8.4-2.fc19.i686
evolution-data-server-0:3.8.3-1.fc19.i686
evolution-data-server-0:3.8.4-1.fc19.i686
evolution-ews-0:3.8.3-1.fc19.i686
evolution-mapi-0:3.8.3-1.fc19.i686
evolution-mapi-0:3.8.4-1.fc19.i686
folks-1:0.9.2-3.fc19.i686
freeDiameter-0:1.1.6-1.fc19.i686
freetds-0:0.91-6.gitf3ae29d.fc19.i686
ggz-base-libs-0:0.99.5-12.fc19.i686
giggle-0:0.7-2.fc19.i686
gloox-1:1.0-5.11.fc19.i686
gnustep-base-libs-0:1.24.4-7.fc19.i686
gnutls-c++-0:3.1.11-1.fc19.i686
gnutls-dane-0:3.1.11-1.fc19.i686
gnutls-devel-0:3.1.11-1.fc19.i686
gtk-vnc-0:0.5.2-1.fc19.i686
gtk-vnc2-0:0.5.2-1.fc19.i686
gvnc-0:0.5.2-1.fc19.i686
gvncpulse-0:0.5.2-1.fc19.i686
gwenhywfar-0:4.3.3-1.fc19.i686
gwenhywfar-gui-qt4-0:4.3.3-1.fc19.i686
iksemel-0:1.4-6.fc19.i686
jana-0:0.4.5-0.30.20100520gitacd72f2.fc19.i686
lftp-0:4.4.6-1.fc19.i686
lftp-0:4.4.8-1.fc19.i686
libcacard-2:1.4.2-3.fc19.i686
libcacard-2:1.4.2-4.fc19.i686
libcurl-0:7.29.0-6.fc19.i686
libcurl-0:7.29.0-7.fc19.i686
libepc-0:0.4.0-5.fc19.i686
libepc-ui-0:0.4.0-5.fc19.i686
libetpan-0:1.1-5.fc19.i686
libfprint-0:0.5.0-2.fc19.i686
libgadu-0:1.11.2-1.fc19.1.i686
libgpod-0:0.8.2-9.fc19.i686
libguestfs-1:1.22.2-1.fc19.i686
libguestfs-1:1.22.5-1.fc19.i686
libimobiledevice-0:1.1.5-1.fc19.i686
libinfinity-0:0.5.3-2.fc19.i686
libinfinity-gtk-0:0.5.3-2.fc19.i686
libmicrohttpd-0:0.9.27-1.fc19.i686
liboauth-0:0.9.7-2.fc19.i686
libprelude-1:1.0.0-17.fc19.i686
libpreludedb-1:1.0.0-16.fc19.i686
libprelude-devel-1:1.0.0-17.fc19.i686
libpurple-0:2.10.7-2.fc19.i686
libpurple-0:2.10.7-3.fc19.i686
libtpms-0:0.5.1-17.fc19.i686
libvirt-client-0:1.0.5.1-1.fc19.i686
libvirt-client-0:1.0.5.4-1.fc19.i686
libvmime-0:0.9.2-0.6.20130320git.fc19.i686
libvncserver-0:0.9.9-7.fc19.i686
libxradius-0:0.4.6-17.fc19.i686
loudmouth-0:1.4.3-12.fc19.i686
mate-settings-daemon-0:1.6.0-2.fc19.i686
mate-settings-daemon-0:1.6.1-2.fc19.i686
mod_revocator-0:1.0.3-15.fc19.i686
mod_revocator-0:1.0.3-17.fc19.i686
neon-0:0.29.6-6.fc19.i686
net6-0:1.3.14-4.fc19.i686
NetworkManager-1:0.9.8.2-2.fc19.i686
NetworkManager-1:0.9.8.2-8.git20130709.fc19.i686
NetworkManager-glib-1:0.9.8.2-2.fc19.i686
NetworkManager-glib-1:0.9.8.2-8.git20130709.fc19.i686
nntpgrab-core-0:0.7.2-4.fc19.i686
nordugrid-arc-0:3.0.1-1.fc19.i686
nordugrid-arc-0:3.0.2-1.fc19.i686
nordugrid-arc-plugins-globus-0:3.0.1-1.fc19.i686
nordugrid-arc-plugins-globus-0:3.0.2-1.fc19.i686
nss_compat_ossl-0:0.9.6-5.fc19.i686
nss-devel-0:3.15.1-2.fc19.i686
nuxwdog-0:1.0.1-7.fc19.i686
openconnect-0:5.01-1.fc19.i686
openldap-0:2.4.35-4.fc19.i686
openldap-0:2.4.35-5.fc19.i686
openvas-libraries-0:6.0-3.beta5.fc19.i686
pacemaker-cluster-libs-0:1.1.9-0.1.70ad9fa.git.fc19.i686
pacemaker-cluster-libs-0:1.1.9-3.fc19.i686
pacemaker-libs-0:1.1.9-0.1.70ad9fa.git.fc19.i686
pacemaker-libs-0:1.1.9-3.fc19.i686
pam_pkcs11-0:0.6.2-10.fc19.i686
pcp-libs-0:3.8.0-1.fc19.i686
pcp-libs-0:3.8.2-1.fc19.i686
pki-tps-0:10.0.3-1.fc19.i686
qpid-cpp-client-ssl-0:0.20-6.fc19.i686
qpid-cpp-client-ssl-0:0.22-1.1.fc19.i686
redhat-lsb-submod-security-0:4.1-14.fc19.i686
rpm-build-libs-0:4.11.0.1-2.fc19.i686
rpm-build-libs-0:4.11.1-1.fc19.i686
rpm-devel-0:4.11.0.1-2.fc19.i686
rpm-devel-0:4.11.1-1.fc19.i686
rpm-libs-0:4.11.0.1-2.fc19.i686
rpm-libs-0:4.11.1-1.fc19.i686
spice-glib-0:0.19-1.fc19.i686
spice-glib-0:0.20-2.fc19.i686
spice-gtk-0:0.19-1.fc19.i686
spice-gtk-0:0.20-2.fc19.i686
spice-gtk3-0:0.19-1.fc19.i686
spice-gtk3-0:0.20-2.fc19.i686
suricata-0:1.4.1-1.fc19.i686
svrcore-0:4.0.4-9.fc19.i686
syncevolution-libs-1:1.3.99.3-1.fc19.i686
systemtap-devel-0:2.2.1-1.fc19.i686
volume_key-libs-0:0.3.9-3.fc19.i686
wine-core-0:1.5.27-1.fc19.i686
wine-core-0:1.6-1.fc19.i686
wireshark-0:1.10.0-2.fc19.i686
xmlsec1-gnutls-0:1.2.18-4.fc19.i686
xmlsec1-nss-0:1.2.18-4.fc19.i686
xulrunner-0:21.0-8.fc19.i686
xulrunner-0:22.0-4.fc19.i686
Comment 11 Dennis Gilmore 2013-08-07 21:45:10 EDT
it will be included in the tree if its needed by dependencies. if nss or gnutls need it they need to require it.
Comment 12 Stef Walter 2013-08-08 00:55:45 EDT
Dennis, PKCS#11 modules are like plugins. They provide functionality to PKCS#11 consumers. In this case the p11-kit-trust PKCS#11 module provides support for enumerating installed anchors and blacklists.
Comment 13 Tomas Mraz 2013-08-08 04:17:01 EDT
Is there a way to explicitly declare a package multilib (in comps or somewhere else?).
Comment 14 Bill Nottingham 2013-08-08 14:54:34 EDT
Yes, in mash. See:
  https://git.fedorahosted.org/cgit/mash/tree/mash/multilib.py

Looks like we want to mark any package that places files in /usr/lib{,64}/pkcs11/ ?
Comment 15 Kai Engert (:kaie) 2014-06-10 09:58:23 EDT
We had failed to follow up after Bill's comment, and to confirm his question. Sorry. This issue just came up again in bug 1060764.

Yes, I'd agree with comment 14, any package that places files into /usr/lib{,64}/pkcs11/ should be build for all arches on a multilib arch.

How can we make that happen?
Who is able to make that change to the mash multilib.py script?

Thanks in advance!
Comment 16 Stef Walter 2014-08-07 02:59:11 EDT
*** Bug 1060764 has been marked as a duplicate of this bug. ***
Comment 17 Fedora End Of Life 2015-01-09 17:14:19 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

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 19 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.
Comment 18 Fedora End Of Life 2015-02-18 09:03:15 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 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.
Comment 19 Kai Engert (:kaie) 2017-07-25 10:50:06 EDT
This issue still frustrates me, so I'll open it.

The issue is the inconsistency. We advertise the ability to install a CA for systemwide use by most applications, but because p11-kit-trust.i686 is missing, NSS.i686 and GnuTLS.i686 applications don't get the CAs the admin has installed.

I wonder why we haven't gotten more bug reports about this issue. Is nobody using 32-bit applications any more for SSL/TLS?

Let's try the suggestion from comment 11.

I see that on Fedora 25, it's no longer possible to uninstall the primary p11-kit-trust.rpm package, as several important packages depend on it (sudo/systemd/dnf/systemd-udev).

How about a new "dummy" nss subpackage, that installs nothing, but requires p11-kit-trust? Would that be sufficient to get it into the compose, even if that NSS subpackage usually isn't installed?
Comment 20 Kai Engert (:kaie) 2017-07-25 12:56 EDT
Created attachment 1304347 [details]
experimental patch v1

Daiki, how about adding something like this attachment to the nss package (rawhide for testing it)?

Here is a scratch build:
https://koji.fedoraproject.org/koji/taskinfo?taskID=20725696

I was able to install it locally in a rawhide VM (excluding the new dummy package).

If I understand correctly, as soon as we build this in koji, the fedora compose will include p11-kit-trust.i686?
Comment 21 Kevin Fenzi 2017-07-25 17:44:20 EDT
So, this is actually in the pungi whitelist, so it should be included: 

https://pagure.io/pungi-fedora/blob/master/f/fedora.conf#_182

and indeed I see it there: 

http://dl.fedoraproject.org/pub/fedora/linux/development/rawhide/Everything/x86_64/os/Packages/p/p11-kit-0.23.7-1.fc27.i686.rpm

So, whats still wrong here?
Comment 22 Daiki Ueno 2017-07-26 04:31:54 EDT
It was fixed recently by rel-eng as part of bug 1456239:
https://pagure.io/releng/issue/6855
though it's only for Fedora 26 or later.

The dependency based approach was also attempted in the gnutls package, but it apparently didn't work and caused some other issues, according to Nikos:
http://pkgs.fedoraproject.org/cgit/rpms/gnutls.git/commit/?id=5651d6db313d5d2a15f7efe6b05c7eb85cfdb30b

I would suggest to ensure that the dependency based approach is supposed to work and doesn't cause any problem, if the approach is preferable.

On a bit different note, I think every package which contains a PKCS#11 module (i.e. *.so file under %_libdir/pkcs11/) should be marked as multilib.  Isn't it possible to implement it in the compose tool?
Comment 23 Tomas Mraz 2017-07-26 04:49:36 EDT
And isn't the situation such that adding the requires to a package is not sufficient for making the package multilib - but that was already solved by the pungi whitelist. And now we actually need to pull the package in on the install - which basically means the gnutls and/or nss should now get the arch specific requires and it should not cause any problems anymore because the package is now in the repository.

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