Hello, I have a question for someone with deep knowledge about
cryptology. The question regards Fedora's crypto policies and a certain
usage of SHA-1 in TLS.
I encountered a web server that Seamonkey and Firefox refuse to talk
to. Both give me the error SSL_ERROR_UNSUPPORTED_SIGNATURE_ALGORITHM.
In an attempt to find out more, I checked the server with Qualys' SSL
Server Test (https://www.ssllabs.com/ssltest/). Qualys gave it an A+,
which is supposed to mean that its security is excellent.
Next I used Wireshark to inspect the TLS handshake. Wireshark reported
usage of SHA-1, not in the certificate but in a signature associated
with elliptic curve parameters:
| TLSv1.2 Record Layer: Handshake Protocol: Server Key Exchange
| Content Type: Handshake (22)
| Version: TLS 1.2 (0x0303)
| Length: 333
| Handshake Protocol: Server Key Exchange
| Handshake Type: Server Key Exchange (12)
| Length: 329
| EC Diffie-Hellman Server Params
| Curve Type: named_curve (0x03)
| Named Curve: secp256r1 (0x0017)
| Pubkey Length: 65
| Pubkey: 041f840f40a2178f875274097092ca2549138f8a7bd52df895ea413b742d1714a6cf873e…
| Signature Algorithm: rsa_pkcs1_sha1 (0x0201)
| Signature Hash Algorithm Hash: SHA1 (2)
| Signature Hash Algorithm Signature: RSA (1)
| Signature Length: 256
| Signature: 09147d81aa601dc402e62cf7f943196c89822a0c8bbe07d8443654519b0e04f51b0b8e72…
To check whether this was the problem, I temporarily added "SHA1" to
/etc/crypto-policies/back-ends/nss.config. This made the error go away,
and the browser happily loaded the page.
My question is: Is it true that this usage of SHA-1 makes the TLS
session weak, so that it's correct to forbid it in the crypto policy?
Or could it be that Qualys is right? Perhaps SHA-1 is fine for this use
case, even though it's too weak for other use cases, and the crypto
policy should allow it?
The website where I saw this is https://www.euroclear.com/ in case
anyone wants to test things themself.
I am planning to start a retirement process for quagga in Fedora. The
package is very outdated since the upstream is dead for a couple of
years. There is a replacement in the form of FRR that can be used in a
very similar fashion and it has active upstream with a lot of
development going on.
This is more of an FYI message to let you know and to see if anyone
would miss quagga.
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
I would like to put out a public call for a new primary owner for ImageMagick.
I only picked it up a few years ago to prevent it from being orphaned, but I no
longer have the desire or time to maintain it.
== Summary ==
The ansible project has re-organized how they release and distribute
ansible. This change moves Fedora to be in sync with those changes and
retires the old 'ansible classic/2.9.x' package in favor of a
'ansible' package that pulls in ansible-core (the engine) and includes
all the collections in upstream ansible releases.
== Owner ==
* Name: [[User:kevin| Kevin Fenzi]] and [[User:dmsimard]]
* Email: kevin(a)scrye.com, dmsimard(a)redhat.com
== Detailed Description ==
The upstream ansible project found that maintaining a single
monolithic ansible package with everything included was not working
source]). Small changes had to wait for releases, some areas had no
subject matter reviewers, it was difficult to try and handle all the
issues and changes in a timely manner. So, the ansible engine was
split off and then the rest of the content was moved to separate
collections. These collections could then be maintained by communities
that care about that area and could release at their own pace. A
number of collections have agreed to release on the same cadence.
These collections, along with the ansible-core engine comprise a
upstream 'ansible' release.
The engine package (ansible-core) is already in Fedora 35+. Currently
the 'ansible' package is 'ansible classic', ie, the 2.9.x version from
before the reorganization. While Ansible 2.9.x will continue to be
maintained from a security perspective until 2022, it is desireable to
update to the latest release of both ansible-core and ansible in order
to benefit from continued updates, bug fixes and improvements.
This change will modify the existing 'ansible' package to include the
Ansible Collections that are provided in the upstream ansible releases
from PyPi. The ansible package will not include ansible-core but will
have a requirement (dependency) on it.
Having two separate packages will give users the ability to select the
best option based on their needs:
# Install the 'ansible' package to mirror the user experience when
installing ansible from PyPi: it will install ansible-core as well as
the collections as they are included in the upstream ansible release.
# Install just the 'ansible-core' package when no external collections
# Install 'ansible-core' and then manually install collections either
from existing [https://koji.fedoraproject.org/koji/search?match=glob&type=package&terms=...
packages in Fedora], from [https://galaxy.ansible.com/ Ansible Galaxy]
== Benefit to Fedora ==
* On current upstream releases with bugfixes and enhancements.
* Increases flexibility by allowing users to choose which Ansible
collections to install and where they install it from.
* More rapid improvements for Fedora users.
== Scope ==
* Proposal owners: 'ansible' package needs to be modified for this
change (work is in progress already).
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: Possibly policies for packaging collections?
* Trademark approval: N/A (not needed for this Change
* Alignment with Objectives:
== Upgrade/compatibility impact ==
On upgrade, ansible-2.9.x will be replaced by ansible-core + release
collections. Ansible playbooks will continue to run as before.
== How To Test ==
Playbooks that run as expected under Ansible 2.9 may behave
differently under Ansible 5 which effectively updates the
(ansible-core) runtime from 2.9 to 2.12.
Users are encouraged to take a look at the available porting guides
for both Ansible and ansible-core
and carefully test the behavior of their roles and playbooks in case
of any adjustments are needed.
The Ansible community package follows semantic versioning rules, so
incompatible changes are only made between major versions.
Unfortunately in this case, there are a number of major versions
between 2.9 and 5.0.
== User Experience ==
Users can remove the release collections and install separately
packaged collections or install from ansible-galaxy.
== Dependencies ==
Might need to conflict with some seperately packaged collections.
== Contingency Plan ==
* Contingency mechanism: Keep shipping ansible classic, but it will go
EOL and updates will become much harder.
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? N/A (not a System Wide Change)
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Ansible is now shipped as 'ansible-core' (the engine) and a curated
set of Ansible collections.
Users can use 'dnf install ansible' to install ansible-core as well as
the Ansible collections included in the upstream Ansible releases.
Users can also opt to 'dnf install ansible-core' and then install
collections manually from standalone packages or via ansible-galaxy.
He / Him / His
Fedora Program Manager