crypto-policies and a certain usage of SHA-1
by Björn Persson
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.
Björn Persson
7 minutes
Removal of quagga from Fedora
by Michal Ruprich
Hi,
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.
Cheers,
--
Michal Ruprich
Software Engineer
Email: mruprich(a)redhat.com
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic
41 minutes
ImageMagick update
by Luya Tshimbalanga
Hello everyone,
ImageMagick is now pushed to 6.9.12.25 as a long-overdue update [1] for
all releases except EPEL8 branch, which I do not use (co-maintainer
welcome). Affected packages below may need to rebuild:
NsCDE
a2ps
anyremote
c-graph
caja-image-converter
chordpro-abc
conky-manager
darktable-tools-noise
devedeng
dvd-slideshow
epix
fbida
ffmulticonverter
freewrl
geeqie
gscan2pdf
gyazo
jumpnbump-menu
latex2rtf
libpst
lives
lyx
mediawiki
mtpaint
nautilus-image-converter
nemo-image-converter
perl-Graphics-TIFF-tests
perl-PDF-API2-tests
perl-PDF-Builder-tests
perl-Panotools-Script
playonlinux
rubygem-mini_magick
rubygem-rmagick
shutter
texlive-graphicxpsd
variety
vfrnav-utils
w3m-img
wdune
References:
--------------
[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=77256767
[2] https://bodhi.fedoraproject.org/updates/?packages=ImageMagick
--
Luya Tshimbalanga
Fedora Design Team
Fedora Design Suite maintainer
1 hour, 56 minutes
F37 Change: Ansible 5 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Ansible5
== 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
well ([https://www.ansible.com/blog/thoughts-on-restructuring-the-ansible-project
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
are necessary
# 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]
or elsewhere.
== 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
(https://docs.ansible.com/ansible/devel/porting_guides/porting_guides.html)
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.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
8 hours, 40 minutes
