Bug 1396719 - FUTURE cryptopolicy prevent dnf from updating
Summary: FUTURE cryptopolicy prevent dnf from updating
Alias: None
Product: Fedora
Classification: Fedora
Component: curl
Version: 25
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Kamil Dudka
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2016-11-19 08:54 UTC by Michael S.
Modified: 2016-11-29 05:51 UTC (History)
4 users (show)

Fixed In Version: curl-7.51.0-3.fc26 curl-7.51.0-3.fc25
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-11-26 22:52:57 UTC
Type: Bug

Attachments (Terms of Use)

Description Michael S. 2016-11-19 08:54:45 UTC
Description of problem:

last week, I switched cryptopolicy to FUTURE in /etc/cryptopolicy/config and promptly forgot about it. 

And today, while trying to update my Fedora system, i was greeted by dnf errors regarding mirror likst for rpmfusion, then fedora, with in the end the following issue:

# curl 'https://mirrors.fedoraproject.org/metalink?repo=fedora-25&arch=x86_64'                                                          
curl: (35) SSL version range is not valid.  

So using FUTURE mean that we can't update the system, and that seems a bit annoying. 

There is several issue here to fix:
- the error message is quite puzzling on dnf side, and also on curl side.
- the "FUTURE" is either not usable systemwide

So should the setting be more adapted, or should something should be changed on Fedora side to use proper cipher ? 

Version-Release number of selected component (if applicable):

How reproducible:
each time

Steps to Reproduce:
1. set FUTURE in /etc/cryptopolicy/config
2. udate-cryptopolicy
3. run dnf update

Actual results:
puzzling error message

Expected results:
stuff should be working

Additional info:

Comment 1 Michael S. 2016-11-19 10:20:12 UTC
so after doing some fiddling, the issue is:

anything different from tls-version-min=tls1.0 fail. I am not sure if the issue is on curl side, or on the cryptopolicy side

Comment 2 Nikos Mavrogiannopoulos 2016-11-21 07:43:21 UTC
It seems the issue is in curl. If I provide explicitly TLS1.2 it works:

$ curl --tlsv1.2 https://www.google.com
<HTML><HEAD><meta http-equiv="content-type" content="text/html;charset=utf-8">


$ curl https://www.google.com
curl: (35) SSL version range is not valid.

It seems its code cannot cope with NSS having TLS 1.0 or TLS 1.1 disabled.

Comment 3 Kamil Dudka 2016-11-21 08:45:13 UTC
Thank you for reporting the bug!  The following upstream commit will fix it:


Comment 4 Kamil Dudka 2016-11-21 09:09:13 UTC
I have also included the --tlsv1.3 option to ease future testing of TLS 1.3:


Comment 5 Nikos Mavrogiannopoulos 2016-11-21 09:13:33 UTC
Kamil could you include that fix in F25 as well? F25 is the first release with NSS supporting crypto policies.

Comment 6 Kamil Dudka 2016-11-21 09:21:49 UTC
(In reply to Nikos Mavrogiannopoulos from comment #5)
> Kamil could you include that fix in F25 as well?

Sure.  It is already included in dist-git (master and f25 share the same commit object).  I am only waiting with the f25 build till the rawhide build finishes.  Otherwise both the builds would fail due to port collisions in the upstream test suite in case a pair of builds was accidentally assigned to the same build host in Koji.

Comment 7 Fedora Update System 2016-11-21 10:41:07 UTC
curl-7.51.0-3.fc25 has been submitted as an update to Fedora 25. https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f35ce8775

Comment 8 Fedora Update System 2016-11-23 23:06:11 UTC
curl-7.51.0-3.fc25 has been pushed to the Fedora 25 testing repository. If problems still persist, please make note of it in this bug report.
See https://fedoraproject.org/wiki/QA:Updates_Testing for
instructions on how to install test updates.
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2016-0f35ce8775

Comment 9 Fedora Update System 2016-11-26 22:52:57 UTC
curl-7.51.0-3.fc25 has been pushed to the Fedora 25 stable repository. If problems still persist, please make note of it in this bug report.

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