Bug 1390598

Counter arguments:

- p11-kit-trust was implemented as a drop in replacement for functionality
  that was originally provided by NSS.

  Your change would require that any process that currently uses NSS,
  would also start to depend on OpenSSL

- OpenSSL might eventually get enhanced to use p11-kit-trust, too,
  which would implement a circular dependency

- p11-kit-trust doesn't require all of NSS.
  It only requires one of the sub-packages of NSS, nss-softokn-freebl.
  As a result, if your minimal environment doesn't pull in NSS for other
  reasons, you don't require full NSS.

I see that glibc also depends on libfreebl3.so, which means, by changing p11-kit-trust, apparently you couldn't get rid of the dependency on nss-softokn-freebl.

(In reply to Kai Engert (:kaie) from comment #1)
> - p11-kit-trust doesn't require all of NSS.
>   It only requires one of the sub-packages of NSS, nss-softokn-freebl.
>   As a result, if your minimal environment doesn't pull in NSS for other
>   reasons, you don't require full NSS.

Exactly. Perhaps we can drop the requirement from the RPM, and just use that library opportunistically? We would need to dlopen() the library and do that dance, but it's just for 6 function calls. What do you think, Daiki?

(In reply to Stef Walter from comment #3)
> Exactly. Perhaps we can drop the requirement from the RPM, and just use that
> library opportunistically? We would need to dlopen() the library and do that
> dance, but it's just for 6 function calls. What do you think, Daiki?

But wouldn't that mean that some p11-kit-trust functionality would no longer work in the minimal environment, if freebl is absent? Are such failures acceptable?

(In reply to Kai Engert (:kaie) from comment #4)
> (In reply to Stef Walter from comment #3)
> > Exactly. Perhaps we can drop the requirement from the RPM, and just use that
> > library opportunistically? We would need to dlopen() the library and do that
> > dance, but it's just for 6 function calls. What do you think, Daiki?
> 
> But wouldn't that mean that some p11-kit-trust functionality would no longer
> work in the minimal environment, if freebl is absent? Are such failures
> acceptable?

We only use the NSS functionality to meet certification criteria. If the minimal runtime does not need to meet those criteria then the fallback can be used. The fallback code is already present.

(In reply to Kai Engert (:kaie) from comment #2)
> I see that glibc also depends on libfreebl3.so, which means, by changing
> p11-kit-trust, apparently you couldn't get rid of the dependency on
> nss-softokn-freebl.

Where do you see that? There's no dependency that I can find in glibc...

(In reply to Stephen Gallagher from comment #6)
> 
> Where do you see that? There's no dependency that I can find in glibc...

rpm -q --requires glibc |grep -i freebl

libfreebl3.so()(64bit)
libfreebl3.so(NSSRAWHASH_3.12.3)(64bit)
libfreebl3.so
libfreebl3.so(NSSRAWHASH_3.12.3)

(In reply to Stef Walter from comment #5)
> (In reply to Kai Engert (:kaie) from comment #4)
> > (In reply to Stef Walter from comment #3)
> > > Exactly. Perhaps we can drop the requirement from the RPM, and just use that
> > > library opportunistically? We would need to dlopen() the library and do that
> > > dance, but it's just for 6 function calls. What do you think, Daiki?
> > 
> > But wouldn't that mean that some p11-kit-trust functionality would no longer
> > work in the minimal environment, if freebl is absent? Are such failures
> > acceptable?
> 
> We only use the NSS functionality to meet certification criteria. If the
> minimal runtime does not need to meet those criteria then the fallback can
> be used. The fallback code is already present.

If we can support fallback without freebl, then the right move here (I think) would be to switch this to a Recommends: dependency rather than a Requires:

(In reply to Kai Engert (:kaie) from comment #7)
> (In reply to Stephen Gallagher from comment #6)
> > 
> > Where do you see that? There's no dependency that I can find in glibc...
> 
> rpm -q --requires glibc |grep -i freebl
> 
> libfreebl3.so()(64bit)
> libfreebl3.so(NSSRAWHASH_3.12.3)(64bit)
> libfreebl3.so
> libfreebl3.so(NSSRAWHASH_3.12.3)


What version of glibc is that? On my system:

`rpm -q glibc-2.24-3.fc25.x86_64 --requires |grep freebl`

returns nothing at all.

That was on F24.

(In reply to Stephen Gallagher from comment #9)
> (In reply to Kai Engert (:kaie) from comment #7)
> > (In reply to Stephen Gallagher from comment #6)
> > > 
> > > Where do you see that? There's no dependency that I can find in glibc...
> > 
> > rpm -q --requires glibc |grep -i freebl
> > 
> > libfreebl3.so()(64bit)
> > libfreebl3.so(NSSRAWHASH_3.12.3)(64bit)
> > libfreebl3.so
> > libfreebl3.so(NSSRAWHASH_3.12.3)
> 
> 
> What version of glibc is that? On my system:
> 
> `rpm -q glibc-2.24-3.fc25.x86_64 --requires |grep freebl`
> 
> returns nothing at all.


OK, looks like this changed in Fedora 25. glibc no longer depends on libfreebl3.so. (I suspect this may have something to do with the libcrypt vs. libcrypt-nss change)

In any case, since we're looking at F26+ for these changes, glibc isn't an issue.

I wonder if the rpm querying works correctly, because it might dynamically open the freebl lib.

For example, the following (from a f25 VM) looks strange, no?

[root@localhost ~]# rpm -q --whatrequires nss-softokn-freebl
no package requires nss-softokn-freebl
[root@localhost ~]# dnf erase nss-softokn-freebl
Dependencies resolved.
Error: The operation would result in removing the following protected packages: systemd-udev, dnf, systemd.

(In reply to Kai Engert (:kaie) from comment #12)
> I wonder if the rpm querying works correctly, because it might dynamically
> open the freebl lib.
> 
> For example, the following (from a f25 VM) looks strange, no?
> 
> [root@localhost ~]# rpm -q --whatrequires nss-softokn-freebl
> no package requires nss-softokn-freebl
> [root@localhost ~]# dnf erase nss-softokn-freebl
> Dependencies resolved.
> Error: The operation would result in removing the following protected
> packages: systemd-udev, dnf, systemd.

That's because `rpm -q --whatrequires` is pretty stupid. It only checks for things that have literally "Requires: nss-softokn-freebl". It doesn't include checks for other things that package Provides:

Try
`dnf repoquery --whatrequires nss-softokn-freebl --alldeps` and you get:

chrony-0:2.4-3.fc25.x86_64
dracut-fips-0:044-77.fc25.x86_64
libcrypt-nss-0:2.24-3.fc25.i686
libcrypt-nss-0:2.24-3.fc25.x86_64
libtpms-0:0.5.2-7.fc24.i686
libtpms-0:0.5.2-7.fc24.x86_64
nss-softokn-0:3.27.0-1.0.fc25.i686
nss-softokn-0:3.27.0-1.0.fc25.x86_64
nss-softokn-freebl-devel-0:3.27.0-1.0.fc25.i686
nss-softokn-freebl-devel-0:3.27.0-1.0.fc25.x86_64
p11-kit-trust-0:0.23.2-2.fc24.x86_64

CCing Florian and Carlos from the glibc team to chime in on the questions above.

p11-kit just needs MD5 and SHA1. Many projects, including GLib, include this code directly. So pragmatically, p11-kit should be able to include this code. But security is not pragmatic.

Therefore on Fedora and RHEL it doesn't include MD5 or SHA1 code. It #ifdefs it out and uses freebl instead.

p11-kit can use whatever makes sense for the certification requirements on RHEL and Fedora. Up until now that was freebl ... if it should be something else then it's not a problem to adapt.

Stephen, feel free to duke this out, and come up with a solution either way. The discussion will be *much* longer than the resulting patch.

(In reply to Stephen Gallagher from comment #14)
> CCing Florian and Carlos from the glibc team to chime in on the questions
> above.

In F26+ glibc is not an issue.

We removed the NSS requirement in F25 to allow an install without NSS.

https://bugzilla.redhat.com/show_bug.cgi?id=1324623#c0

Does that answer your question?

(In reply to Carlos O'Donell from comment #17)
> (In reply to Stephen Gallagher from comment #14)
> > CCing Florian and Carlos from the glibc team to chime in on the questions
> > above.
> 
> In F26+ glibc is not an issue.
> 
> We removed the NSS requirement in F25 to allow an install without NSS.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1324623#c0
> 
> Does that answer your question?

Note that such an install may no longer be capable of FIPS 140 compliance.

(In reply to Carlos O'Donell from comment #18)
> (In reply to Carlos O'Donell from comment #17)
> > (In reply to Stephen Gallagher from comment #14)
> > > CCing Florian and Carlos from the glibc team to chime in on the questions
> > > above.
> > 
> > In F26+ glibc is not an issue.
> > 
> > We removed the NSS requirement in F25 to allow an install without NSS.
> > 
> > https://bugzilla.redhat.com/show_bug.cgi?id=1324623#c0
> > 
> > Does that answer your question?
> 
> Note that such an install may no longer be capable of FIPS 140 compliance.

OK, the details of that will be discussed elsewhere. The main concern here was to point out that glibc is not on its own going to bind us to using NSS in the base runtime.

With glibc off the table, the only two remaining packages pulling in NSS are p11-kit-trust and rpm. RPM is being tracked in BZ #1390624.

From a purely high-level perspective, I don't particularly care whether p11-kit-trust is modified to compile against OpenSSL or if it uses its own md5 and SHA1 implementations in Fedora. It's worth noting that md5 and sha1 have been given explicit exceptions in the past to the bundling policy (due mostly to the ubiquity of projects doing so). See https://fedoraproject.org/wiki/Bundled_Libraries_Virtual_Provides which indicates that these algorithms are considered copylibs under Fedora rules.

If those internal implementations already exist, I'd suggest the following:

1) Modify the RPM to build against the internal implementation rather that NSS.
2) Work on an OpenSSL, FIPS-140 compliant implementation for down the road.

This way we can move ahead with the NSS removal without waiting for code changes.

RPM does much more than just MD5/SHA*. But I believe you meant p11-kit here.

(In reply to Tomas Mraz from comment #20)
> RPM does much more than just MD5/SHA*. But I believe you meant p11-kit here.

Sorry, that should have read:

1) Modify p11-kit-trust's RPM spec to build against...


I can see how that would have been unclear.

Unless there is already internal code for MD5 and SHA it would be probably similar effort to add it as to replace NSS with OpenSSL library calls.

There is internal code, and a relevant configure option. This is the change that would need to happen to the RPM spec file:

diff --git a/p11-kit.spec b/p11-kit.spec
index 15685f6..9762c0a 100644
--- a/p11-kit.spec
+++ b/p11-kit.spec
@@ -9,7 +9,6 @@ Source0:        http://p11-glue.freedesktop.org/releases/p11-kit-%{version}.tar.
 Source1:        trust-extract-compat
 
 BuildRequires:  libtasn1-devel >= 2.3
-BuildRequires:  nss-softokn-freebl
 BuildRequires:  libffi-devel
 BuildRequires:  gtk-doc
 
@@ -55,7 +54,7 @@ contains certificate anchors and black lists.
 %build
 # These paths are the source paths that  come from the plan here:
 # https://fedoraproject.org/wiki/Features/SharedSystemCertificates:SubTasks
-%configure --disable-static --enable-doc --with-trust-paths=%{_sysconfdir}/pki/ca-trust/source:%{_datadir}/pki/ca-trust-source --with-hash-impl=freebl --disable-silent-rules
+%configure --disable-static --enable-doc --with-trust-paths=%{_sysconfdir}/pki/ca-trust/source:%{_datadir}/pki/ca-trust-source --disable-silent-rules
 make %{?_smp_mflags} V=1
 
 %install

OK, this conversation seems to have stalled out. When last we left off, it sounded (to me) like my comment #19 was a reasonable short and longer-term approach.

Stef provided a simple patch we can use in the spec file to switch it to using the internal hash implementation for the immediate future. Daiki, would you consider applying this patch for now, so we can eliminate the nss-softokn-freebl dependency?

Once this happens, I'll open a new BZ for adding support for using OpenSSL to provide that hash implementation.


Also, as a general note for Kai: I want to make it clear that this request has nothing to do with real or perceived issues with NSS. It's purely a game of numbers: we want to reduce the number of crypto implementations in the Base Runtime, and far fewer packages in the relevant set are currently configured to use NSS (only two - p11-kit and rpm, both of which have pluggable crypto - compared to over a dozen using OpenSSL, most of which have no plugin model).

(In reply to Stephen Gallagher from comment #24)
> Stef provided a simple patch we can use in the spec file to switch it to
> using the internal hash implementation for the immediate future. Daiki,
> would you consider applying this patch for now, so we can eliminate the
> nss-softokn-freebl dependency?

Done in rawhide.

Thanks!

If this bug is done, should it be closed?

The question is if we are OK with it using internal hash implementation or if we want to further patch it to use OpenSSL.

The only reason to depend on a crypto lib is because of FIPS140, but given the above discussion (SHA1 here is not used for crypto purposes), this is not be required. My take would be that it is better to keep this package without any crypto dependencies (because all crypto libs depends on it).

I agree.

Let's close this as fixed then.