Resending this as a new thread, for increased visibility.
As explained in the older thread, the Mozilla project has started to
remove CA certificates that contain weak keys. Those removals cause
issues with software based on OpenSSL, and software based on older
versions of GnuTLS.
(A short description of the issue can be found in tracker bug
https://bugzilla.redhat.com/show_bug.cgi?id=1166614 - I intend to file a
ticket against OpenSSL shortly.)
For Fedora, we have decided to keep the legacy CA certificates included
and trusted by default, in order to avoid compatibility issues, until we
get functional updates to OpenSSL.
I'm documenting the changes on top of the Mozilla CA
list at: https://fedoraproject.org/wiki/CA-Certificates
However, we want to provide users/administrators with the ability to
change the default, by configuring the ca-certificates to strictly
follow the trust decisions made by Mozilla, thereby accepting the
compatibility issues (e.g. untrusted TLS connections, if certificates of
affected server configurations cannot be validated).
The above has been implemented for Fedora 21, it looks like it will be
included as part of the Fedora 21 release:
Using the new ca-legacy utility, it is possible to disable trust for the
legacy CA certificates as a systemwide configuration, by executing this
command as root:
The configuration will be remembered in /etc/pki/ca-trust/ca-legacy.conf
and will be used on future package upgrades, when additional
certificates are moved to the legacy state.
If required, it's possible to undo the configuration and revert to the
current default, using:
The current configuration can be shown using:
Regarding Fedora 19 and Fedora 20:
On F19/F20, GnuTLS is also affected by the breakage, when disabling
trust for the legacy CAs, because GnuTLS has been enhanced in Fedora 21
and later, only.
Updated packages for F19 and F20, that provide the update to version 2.1
of the ca-certificates list, and which also include the new ca-legacy
utility and configuration mechanism, have been pushed to
As you might know ABRT attaches 'environ' file to its Bugzilla bugs. The file
contains a full copy of /proc/[pid]/environ. Even though ABRT highlights
black-listed words and encourages users to review the data before submitting
them, it may happen that the reporter misses something and publishes his secrete
data in 'environ' file.
Do you find 'environ' attachment valuable or is ABRT just publishing personal
I was testing installing Fedora 21 Final RC1 in the free space on a GPT
drive with Windows 8.1 (Lenovo Z40). I'm installing from a USB stick made
from the ISO.
Every time I click "Begin Installation" in Anaconda, it locks up at the
screen where I'm supposed to be able to enter the root password and create
a user account. The message at the bottom is something like "Initializing
setup configuration" (sorry, I can't recall the exact words). I can't click
on anything in Anaconda, but I can switch to a terminal and "kill -9 <pid
of anaconda>" to drop me back to the Live desktop.
I do not get the same problem if I delete all the existing partitions on
the drive and install only Fedora. That proceeds fine. The problem only
seems to exist if I try to install alongside Windows.
My question is: how might I go about troubleshooting this?
Christopher L Tubbs II
This is about bug #1136905 , discussed previously on the systemd list
 and also on our desktop list .
The issue is that systemd-timedated now supports only systemd-timesyncd
for NTP and ignores other NTP services installed on the system. It doesn't
know that chronyd or ntpd is enabled (usually by system-config-date after
the installation) and switching NTP in timedate clients such as
timedatectl and GNOME control center is broken.
If we want to have this working correctly with chronyd/ntpd, at this point
it seems the only reasonable option is to replace systemd-timedated.
timedatex is a new implementation of the timedate interface that was
recently added to Fedora. It reads the list of NTP units from a directory
as systemd-timedated used to do. When installed, systemd will start it for
the timedate bus name instead of systemd-timedated. The timedate clients
should work as expected, please report bugs if not.
One suggestion was to install it as a dependency of the NTP packages.
Is this a good idea? Should this first go through the Fedora change
process or at least be documented somewhere?
I've got a TV schedule grabber script that needs to be run on a more or
less daily basis. That would be good enough, but the script suggests a next
start time in it's output when it completes.
If I can figure out a way to pull that time from the script, is there a way
to pass that to systemd?