Bug 1173577 - Load p11-kit tokens by default
Summary: Load p11-kit tokens by default
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Bob Relyea
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: PKCS11 1173548 1173579 1173581 1173582 1217727 1379116 1520527 1540562 1592206
TreeView+ depends on / blocked
 
Reported: 2014-12-12 12:55 UTC by David Woodhouse
Modified: 2018-07-20 13:34 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1540562 (view as bug list)
Environment:
Last Closed: 2018-07-20 11:56:30 UTC
Type: Bug


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Mozilla Foundation 1161219 -- RESOLVED Load system-configured PKCS#11 tokens by default 2020-12-18 13:10:56 UTC
Mozilla Foundation 1296263 P3 RESOLVED SEGV after loading module in crypto policy 2020-12-18 13:11:27 UTC

Internal Links: 1541095

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


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