This is follow-up work for bug 1144808. See that other bug for the reasons that drive this work. The purpose of this new bug is to: - keep legacy roots enabled by default - allow the system administrator to disable legacy roots - remember the admin's action, making it the new default for future updates In other words, if the admin never acts, future updates will continue to keep legacy roots enabled - as long as we think it's necessary for compatibility reasons with all software packages. If the admin acts once, the system will completely follow the upstream decisions of the Mozilla CA maintainers. If additional roots get disabled/removed, they will get disabled on the system, too. This is an initial implemention, which attempts to be very simple. It would be more difficult to implement a solution that allowed the admin to configure legacy roots independently. (Should such a solution be asked for, it can be implemented using additional follow-up work.) In detail: I've implemented a new utility, ca-legacy which offers the following commands: - enable - disable - check - install The enable command configures the enabled state, which is equivalent to the "no configuration present" state. The disable command configures the disabled state. The configured state is stored in config file /etc/pki/ca-trust/ca-legacy.conf The install command is used to perform the necessary system changes (using a symbolic link), that will either enable or disable legacy certs, based on the configuration file. It is executed at package install time, and when using the enable/disable commands. The check command prints a human readable summary of the current configuration. Legacy certs might be "partially" removed by upstream, that is, a root might have it's trust removed for e.g. TLS, but might still be marked for email security. This is why we must use two alternative lists of roots (and cannot simply enable a file in addition). The input file certdata.txt, as provided by upstream, will be edited by the package maintainer to add new legacy flags, as required for Fedora/OpenSSL/GnuTLS. Each root that contains a legacy flag, will be placed into the separate lists of legacy alternatives.
Packages with this feature are ready for testing: Rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=7965554 Fedora 21 testing: http://koji.fedoraproject.org/koji/taskinfo?taskID=7965585
scratch build for testing with Fedora 20: http://koji.fedoraproject.org/koji/taskinfo?taskID=7965788
Created attachment 951580 [details] Difference between upstream certdata.txt and the edited version with legacy flags
Code: http://pkgs.fedoraproject.org/cgit/ca-certificates.git/commit/?id=e24bfeb6b00079064aa36f3a6c37ecfd036b7043
Updated builds that fix a missing Requires:coreutils rawhide: http://koji.fedoraproject.org/koji/taskinfo?taskID=7974865 f21: http://koji.fedoraproject.org/koji/taskinfo?taskID=7975013 f20 scratch: http://koji.fedoraproject.org/koji/taskinfo?taskID=7975053
ca-certificates-2014.2.1-1.3.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.3.fc21
Package ca-certificates-2014.2.1-1.3.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ca-certificates-2014.2.1-1.3.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-13900/ca-certificates-2014.2.1-1.3.fc21 then log in and leave karma (feedback).
Hmmm, I'd expect that with this update, RubyGems should work, but they don't: $ rpm -q ca-certificates ca-certificates-2014.2.1-5.fc22.noarch $ cat /etc/pki/ca-trust/ca-legacy.conf # legacy=enable : # Certain legacy certs, that have been removed by upstream Mozilla, # are still marked as trusted, if required for backwards compatibility # with cryptographic libraries like openssl or gnutls. # # legacy=disable : # Follow all removal decisions of upstream Mozilla CA maintainers # legacy=enable $ gem install gem2rpm ERROR: Could not find a valid gem 'gem2rpm' (>= 0), here is why: Unable to download data from https://rubygems.org/ - SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz)
ca-certificates-2014.2.1-1.4.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.4.fc21
Package ca-certificates-2014.2.1-1.5.fc21: * should fix your issue, * was pushed to the Fedora 21 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing ca-certificates-2014.2.1-1.5.fc21' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2014-15103/ca-certificates-2014.2.1-1.5.fc21 then log in and leave karma (feedback).
ca-certificates-2014.2.1-1.5.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
(In reply to Vít Ondruch from comment #8) > Hmmm, I'd expect that with this update, RubyGems should work, but they don't: ... > $ gem install gem2rpm > ERROR: Could not find a valid gem 'gem2rpm' (>= 0), here is why: > Unable to download data from https://rubygems.org/ - SSL_connect > returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify > failed > (https://s3.amazonaws.com/production.s3.rubygems.org/latest_specs.4.8.gz) On Rawhide 22 with ENABLED this command works for me, no errors (works on 21, too). > $ cat /etc/pki/ca-trust/ca-legacy.conf ... > legacy=enable More interesting to confirm the configuration is the output of the command ca-legacy check which should report ENABLED (The config file is read on package upgrades only.) I'm confused why it doesn't work for you.
(In reply to Fedora Update System from comment #11) > ca-certificates-2014.2.1-1.5.fc21 has been pushed to the Fedora 21 stable > repository. If problems still persist, please make note of it in this bug > report. Peter, the package wasn't intended for stable yet, only for testing :-( (My previous packaged had been pushed to updates-testing only, with karma disabled.)
Hmmm, interesting, it works now: $ rpm -q ca-certificates ca-certificates-2014.2.1-7.fc22.noarch $ cat /etc/pki/ca-trust/ca-legacy.conf # legacy=enable : # Certain legacy certs, that have been removed by upstream Mozilla, # are still marked as trusted, if required for backwards compatibility # with cryptographic libraries like openssl or gnutls. # # legacy=disable : # Follow all removal decisions of upstream Mozilla CA maintainers # legacy=enable $ ca-legacy check Legacy CAs are set to ENABLED in file /etc/pki/ca-trust/ca-legacy.conf (affects install/upgrade) Status of symbolic link /etc/pki/ca-trust/source/ca-bundle.legacy.crt: /usr/share/pki/ca-trust-legacy/ca-bundle.legacy.enable.crt $ gem install gem2rpm Fetching: gem2rpm-0.10.1.gem (100%) Successfully installed gem2rpm-0.10.1 Parsing documentation for gem2rpm-0.10.1 Installing ri documentation for gem2rpm-0.10.1 Done installing documentation for gem2rpm after 0 seconds 1 gem installed So hopefully, everything is all right. SO problem solved (I hope it is not just due to changes RubyGems upstream is doing/did with their certificates ;)).
(In reply to Vít Ondruch from comment #14) > Hmmm, interesting, it works now: I'm glad to hear about your success :-) > So hopefully, everything is all right. SO problem solved (I hope it is not > just due to changes RubyGems upstream is doing/did with their certificates > ;)). Seems unlikely. If I run ca-legacy disable and then repeat the "gem install gem2rpm" command, then I see the failure you had reported earlier. This seems to confirm that RubyGems indeed uses our system certificates. Then I ran ca-legacy enable and repeated the "gem" command again, and it worked again. So hopefully, when you saw the error at the earlier time, something hasn't configured correctly, and you fixed it afterwards. Please let me know if you ever see the failure again while having things "enable"'d, I really hope won't don't have any kind of intermittent failure.
(In reply to Kai Engert (:kaie) from comment #13) > Peter, the package wasn't intended for stable yet, only for testing :-( Nevertheless, Peter, thanks for having worked on the Requires(post) fix! Since the package seems to work as intended, it should be fine to have pushed it out. For f20/f19, I'd like to push out the same code, however, want start with updates-testing, only. Let's wait for additional feedback and a test period, prior to pushing to stable updates on f20/f19.
ca-certificates-2014.2.1-1.5.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc19
ca-certificates-2014.2.1-1.5.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/ca-certificates-2014.2.1-1.5.fc20
ca-certificates-2014.2.1-1.5.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.
ca-certificates-2014.2.1-1.5.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.