Bug 1390624

In conversations I had in #rpm.org on Freenode, it sounds like NSS is only used for some hashing functions in a plugin for RPM. So swapping it out for OpenSSL should only involve writing an OpenSSL-based plugin (as opposed to significant architectural changes).

Rpm needs crypto for calculating and verifying various digests (MD5, SHA*) and signature verification (DSA + RSA) so it's a bit more complicated than "just some hashing functions" but multiple crypto backends are indeed supported already (NSS and beecrypt, circa 500 LoC each) so no major architectural changes required for that.

I would love to get the NSS elephant off my back but the OpenSSL license is problematic.

Apparently the lawyers have examined this situation previously and have determined that it would be acceptable for Fedora to link against OpenSSL in this situation. From https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F

"However, we consider that the OpenSSL library is a system library, as defined by the GPL, on Fedora and therefore we are allowed to ship GPL software that links to the OpenSSL library."

So we can ship a fork of RPM in Fedora that includes the OpenSSL patches without issue. If we want to ship that plugin upstream, it would be best to get the copyright holders of RPM to agree to add a specific license exception for this as described at http://www.gnu.org/licenses/gpl-faq.html#GPLIncompatibleLibs

Apologies, this got buried and forgotten and just woke up on https://github.com/rpm-software-management/rpm/issues/119: 

As much as I'd like getting rid of NSS, carrying and depending on a Fedora specific patch on something so fundamental as a crypto backend is a non-starter from maintenance POV.

(In reply to Panu Matilainen from comment #4)
> Apologies, this got buried and forgotten and just woke up on
> https://github.com/rpm-software-management/rpm/issues/119: 
> 
> As much as I'd like getting rid of NSS, carrying and depending on a Fedora
> specific patch on something so fundamental as a crypto backend is a
> non-starter from maintenance POV.

Panu, I'm going to be writing the patch in such a way that it *will* be upstreamable. I suggest that you write a message to fedora-legal and ask them for the proper way to reach out to RPM contributors about updating the RPM license to include an exception for linking against OpenSSL, as described in https://fedoraproject.org/wiki/Licensing:FAQ?rd=Licensing/FAQ#What.27s_the_deal_with_the_OpenSSL_license.3F


I am not a lawyer, but I believe there's a legal precedent for making a "good-faith attempt" to reach all of the potential stakeholders. I think it should be possible to email everyone whose email address appears in the git commit logs and offer them an N-month window to reply if they object (as well as announcing the intent on whatever public lists and blogs the project uses).

I'd be very surprised if anyone argued strongly against adding this exception, particularly since using the OpenSSL library will be optional. Any downstream that has an issue with the exception can choose not to use OpenSSL.

Created attachment 1262137 [details]
Switch to OpenSSL (RHBZ #1390624)

Signed-off-by: Igor Gnatenko <ignatenko>

I think it would make sense to switch in rawhide to OpenSSL, so I created patch.

If you think it's good idea, I will commit it and make build.

(In reply to Igor Gnatenko from comment #7)
> I think it would make sense to switch in rawhide to OpenSSL, so I created
> patch.
> 
> If you think it's good idea, I will commit it and make build.

Igor, I'd greatly appreciate it. In fact, I had it on my TODO list today to reach out to the RPM maintainers in Fedora and make that exact request.

Is it possible to have this change made also in Fedora 26? Our first deliverable of the Base Runtime will be coming from Fedora 26 bits. I realize it's a bit late in the cycle, of course.

(In reply to Stephen Gallagher from comment #9)
> Is it possible to have this change made also in Fedora 26? Our first
> deliverable of the Base Runtime will be coming from Fedora 26 bits. I
> realize it's a bit late in the cycle, of course.
I think it doesn't make much sense at this moment because libcurl still links to NSS...

(In reply to Igor Gnatenko from comment #10)
> (In reply to Stephen Gallagher from comment #9)
> > Is it possible to have this change made also in Fedora 26? Our first
> > deliverable of the Base Runtime will be coming from Fedora 26 bits. I
> > realize it's a bit late in the cycle, of course.
> I think it doesn't make much sense at this moment because libcurl still
> links to NSS...

That would be the *other* difficult conversation I'm having today :)

(In reply to Igor Gnatenko from comment #7)
> I think it would make sense to switch in rawhide to OpenSSL, so I created
> patch.
> 
> If you think it's good idea, I will commit it and make build.

If you've tested the result is an actually functional rpm, I've no objections to switching to OpenSSL in rawhide.

The pre-requisite of even considering anything F26 is getting it into rawhide and giving it some proper soak-time there first.

(In reply to Panu Matilainen from comment #12)
> (In reply to Igor Gnatenko from comment #7)
> > I think it would make sense to switch in rawhide to OpenSSL, so I created
> > patch.
> > 
> > If you think it's good idea, I will commit it and make build.
> 
> If you've tested the result is an actually functional rpm, I've no
> objections to switching to OpenSSL in rawhide.
I use it on my laptop for 2 weeks and didn't have problems yet.

Applied in rawhide.