Bug 1173577

Summary: Load p11-kit tokens by default
Product: [Fedora] Fedora Reporter: David Woodhouse <dwmw2>
Component: nssAssignee: Bob Relyea <rrelyea>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: dueno, elio.maldonado.batiz, fran, kdudka, kengert, nmavrogi, stefw, szidek, tuju
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1540562 (view as bug list) Environment:
Last Closed: 2018-07-20 11:56:30 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1173546, 1173548, 1173579, 1173581, 1173582, 1217727, 1379116, 1520527, 1540562, 1592206    

Description David Woodhouse 2014-12-12 12:55:15 UTC
When PKCS#11 tokens are configured in the system's p11-kit, they should be automatically visible to applications.

NSS should be automatically loading the appropriate modules at nss_Init() time in most cases... except possibly NSS_NoDB_Init)( perhaps?

It's also been suggested that we automatically configure the databases in /etc/pki/nssdb and sql:/etc/pki/nssdb to reference p11-kit-proxy.so but that's only useful if we also fix NSS applications to actually *use* those databases. Currently the major applications (Chrome, Firefox, Thunderbird, etc.) don't.

Perhaps the best option is for the nsssoftokn to gain a NSS_ReturnModuleSpecData() entry point, which will enumerate the modules configured by p11-kit and cause them to be loaded?

Comment 1 David Woodhouse 2014-12-12 12:58:06 UTC
In the short term it would be useful to know what applications should be doing if they *care* about being well-behaved. Can they start using SECMOD_LoadUserModule(p11-kit-proxy.so) for themselves, and if so should they make it conditional on something so that they don't continue to do that once NSS has a *proper* fix?

Comment 2 David Woodhouse 2014-12-12 13:36:28 UTC
Oh, one other hack that works surprisingly well in the short term is just symlinking libnssckbi.so to p11-kit-proxy.so instead of p11-kit-trust.so

So any application which wants the trust roots will *also* pull in the default PKCS#11 tokens. It's only the applications *without* the trust roots that don't.

Comment 3 Jan Kurik 2016-07-26 04:16:00 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 25 development cycle.
Changing version to '25'.

Comment 4 David Woodhouse 2016-08-15 09:27:42 UTC
I think we can resolve this in crypto-policies, given the observation in https://bugzilla.redhat.com/show_bug.cgi?id=1157720#c66

Comment 5 David Woodhouse 2016-08-18 12:46:13 UTC
... and a small patch to *fix* the crypto-policy loading, filed upstream as
https://bugzilla.mozilla.org/show_bug.cgi?id=1296263

Now I can add library=p11-kit-proxy.so to the 'nss.txt' crypto policy, and things seem to work as expected.

Comment 6 Nikos Mavrogiannopoulos 2016-09-26 06:10:05 UTC
While setting that into crypto policies makes things work, crypto-policies is the wrong component to address that issue. This component is only about ciphers, protocols and their priority. Adding that fix seems like a non-rational action. If however, we provide a way for generated crypto policies to be amended and the NSS maintainers agree, the nss package could amend the generated policy to add non-policy specific items.

Comment 7 David Woodhouse 2016-09-26 10:01:24 UTC
(In reply to Nikos Mavrogiannopoulos from comment #6)
> While setting that into crypto policies makes things work, crypto-policies
> is the wrong component to address that issue. This component is only about
> ciphers, protocols and their priority.

Is it? Where is that definition written down?

Using the correct PKCS#11 modules is Fedora system policy; it's written in the packaging guidelines.

From the point of view of the NSS package and upstream, it seems that the system policy file is *precisely* the right place to implement such policies.

It was even explicitly referenced in Bob's comment at 
https://bugzilla.redhat.com/show_bug.cgi?id=1157720#c13 where he said
"You can also force loading other PKCS #11 modules (like trust stores) with this, but remember that this affects *ALL* nss programs"

> Adding that fix seems like a non-rational action. If however, we provide a way
> for generated crypto policies to be amended and the NSS maintainers agree, the
> nss package could amend the generated policy to add non-policy specific items.

There is a mass of subjectivity here. All we need to do to make it seem rational, is think of the "crypto policies" package as "system policy for crypto libraries". We wouldn't even need to change the name — just expand our understanding of its scope to cover what it can *already* technically do.

To be honest, I don't actually care *how* we do this or how we justify the minutiæ of the terminology we use. But please, let's make this *work* ASAP. We have the pieces in place to make NSS-using applications conform to Fedora packaging guidelines, right now — they can use the right PKCS#11 providers, and we can reference objects by PKCS#11 URI. All we need to do is merge the patches in the outstanding NSS reviews, and sort out the Fedora system policy.

We ought to be able to do that for Fedora 25; it would be a shame if it had to wait for Fedora 26. And a travesty if we didn't even manage it for F26.

Comment 8 Fedora End Of Life 2017-11-16 19:41:40 UTC
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.

Comment 9 Fedora End Of Life 2018-02-20 15:24:37 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 28 development cycle.
Changing version to '28'.

Comment 10 Daiki Ueno 2018-07-03 12:12:21 UTC
Pushed the relevant changes to nss:
https://src.fedoraproject.org/rpms/nss/c/6f4f615c051ed6204a08973fe13046c05da5cf20?branch=master