Wiki - https://fedoraproject.org/wiki/Changes/Firewalld_IPv6_rpfilter_Default_Loose
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-firewalld-ipv6-r…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Default firewalld to using `IPv6_rpfilter=loose` for new Workstation installs.
== Owner ==
* Name: [[User:erig0| Eric Garver]]
* Email: egarver(a)redhat.com
== Detailed Description ==
Fedora Workstation variants use connectivity checks by default. These
checks can fail for multi-homed hosts where firewalld uses
`IPv6_rpfilter=strict`. As such, for these variants we should instead
default to `IPv6_rpfilter=loose` to allow connectivity checks to
function as intended.
Bug: https://bugzilla.redhat.com/show_bug.cgi?id=2324434
For IPv4 the rpfilter setting is already set to loose by default on
all editions starting with Fedora 30. See:
https://github.com/systemd/systemd/commit/230450d4e4f1f5fc9fa4295ed9185eea5…
== Feedback ==
== Benefit to Fedora ==
The benefit is that connectivity checks will work properly on
multi-homed, e.g. wifi + LAN, workstations. This helps avoid certain
scenarios that can degrade user experience when switching between
modes of connectivity.
== Scope ==
* Proposal owners: The change is a small patch in the RPM spec file.
The only affected file will be `/etc/firewalld/firewalld.conf`.
* Other developers: N/A
* Release engineering: N/A [https://pagure.io/releng/issues #Releng
issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
For systems upgrading to f42, the new value of `IPv6_rpfilter` depends
on whether the user has customized `/etc/firewalld/firewalld.conf`. If
no, then the RPM upgrade process will update the configuration to
`IPv6_rpfilter=loose`. If yes, then the user configuration will be
retained.
It's important to note that this change is a deviation from firewalld
upstream. Firewalld upstream will still default to
`IPv6_rpfilter=strict`.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
No special hardware is required. A default Workstation should be sufficient.
Testing requires multiple network interfaces with internet access.
Connectivity checks must be enabled (default). Tester must verify that
the connectivity checks pass for both links.
== User Experience ==
Connectivity checks work properly for multiple interfaces.
There is one specific scenario in which a non-functioning connectivity
check can lead to a degraded user experience:
A user with a laptop that is connected to their home WiFi connects
said laptop to their home network using Ethernet, for example to
transfer a larger file to a network drive. The user's home network
provides internet access using both IPv4 and IPv6 addressing.
The user expects the Ethernet connection to take precedence over the
already established WiFi connection. However, due to the
`IPv6_rpfilter=strict` setting the IPv6 connectivity check fails and
the Ethernet connection is deemed not connected to the internet.
NetworkManager thus adds a penalty to the Ethernet interface's routing
metric resulting in traffic to the local network and the internet
preferring the WiFi interface over the Ethernet interface. If the WiFi
connection is slower than the Ethernet connection this will lead to a
degraded performance when transferring that large file.
== Dependencies ==
No dependencies.
== Contingency Plan ==
* Contingency mechanism: Keep existing default of `IPv6_rpfilter=strict`.
* Contingency deadline: beta freeze
* Blocks release? No
== Documentation ==
https://bugzilla.redhat.com/show_bug.cgi?id=2324434
== Release Notes ==
Connectivity checks now work properly for multi-homed Workstations.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/FedoraWSL
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-fedora-wsl-self-…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
= Create Fedora Windows Subsystem for Linux Images =
== Summary ==
Recent versions of Windows support running Linux guests via Windows
Subsystem for Linux (WSL). These can be distributed via tarballs, Appx
packages, or via the Windows Store. The purpose of this change is to
start producing Fedora images for users of WSL.
Distributing images via the Windows Store requires agreeing to the
store policies and developer agreement, which is something Fedora has
historically not been comfortable with. This change proposal is to
distribute a tarball. In recent versions of WSL (version 2.4.4 and
greater), the user experience has been greatly improved for WSL images
outside the store. These include allowing tarballs to distribute
first-time setup scripts and icons as part of the distribution instead
of as a Windows application, as well as click-to-install support for
tarballs using the ".wsl" file extension. Therefore, this proposal
will work best with version 2.4.4+ of WSL, although documentation will
be provided for users on older releases.
== Owner ==
* Name: [[User:jcline| Jeremy Cline]]
* Name: [[Cloud SIG]]
* Email: jeremy(a)jcline.org
== Detailed Description ==
Recent versions of Windows support running Linux distributions using
[https://learn.microsoft.com/en-us/windows/wsl/about Windows Subsystem
for Linux] (WSL). In the latest version, WSL 2, a single virtual
machine is managed by the Windows host and guest Linux distributions
run as containers within it. For basic WSL support, Fedora needs to
distribute a root filesystem tarball. The Fedora base container can
already be used with WSL, but it is not ideal as it intentionally
excludes documentation and non-essential tools. There also isn't
official documentation on how to use it with WSL.
The goal of this change is to complete the following:
* Add a WSL variant to https://src.fedoraproject.org/rpms/fedora-release/
* Provide a [https://learn.microsoft.com/en-us/windows/wsl/build-custom-distro#add-the-w…
WSL configuration file and out-of-the-box experience script]
* Create a [https://pagure.io/fedora-kiwi-descriptions/ Kiwi
definition] to produce a WSL root filesystem tarball.
* Write documentation on how to use the tarball with WSL.
* Add our images to the
[https://learn.microsoft.com/en-us/windows/wsl/build-custom-distro#adding-yo…
WSL distribution list] so users can install it with the "wsl --install
Fedora" command.
Optionally, we can include a section on fedoraproject.org to ensure
users can discover our WSL image.
== Feedback ==
== Benefit to Fedora ==
A dedicated image with documentation allows people to easily try out a
Fedora environment from their Windows installations. When it comes
time to install a Linux distribution on their computer, they can be
more confident when choosing Fedora.
== Scope ==
* Proposal owners:
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
== How To Test ==
For WSL versions 2.4.4+:
# Have access to a Windows installation with WSL 2.4.4+
# Run "wsl --install Fedora"
# Enter the environment by running "wsl -d Fedora"
# Use the interactive out-of-the-box experience script to set up a new user
# Install some applications, start some services, see if things fall over.
For WSL versions prior to 2.4.4:
# Have access to a Windows 10 or 11 installation (VMs should work)
# On the Windows host, download the WSL tarball from <somewhere>
# Open up a Windows terminal and install WSL itself with "wsl --install"
# Import the WSL tarball with "wsl --import Fedora
C:\Users\<username>\AppData\Local\WSL\Fedora
.\Path\To\Fedora.x86_64.tar.xz"
# Enter the environment with "wsl -d Fedora -u root"
# manually execute the interactive out-of-the-box experience script to
set up a new user
# Install some applications, start some services, see if things fall over.
== User Experience ==
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Don't ship the tarball
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
Add a section somewhere in https://docs.fedoraproject.org/ (perhaps
quick docs) with a short guide on installing the tarball. This will
cover both older versions of WSL which require more manual steps as
well as the newer, easier method of installation.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Dnf5ExpiredPGPKeys
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-dnf5-expired-key…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Implementing new logic in DNF5 to remove expired and obsolete
repository keys from the system.
== Owner ==
* Name: [[User:jkolarik| Jan Kolarik]]
* Email: jkolarik(a)redhat.com
== Detailed Description ==
We aim to address customer issues when installing RPM packages from
repositories while outdated repository keys are present on the system.
These issues include expired keys, obsolete signing algorithms (e.g.,
SHA1), or other problems that could be easily detected by tools like
an RPM PGP linter. Currently, PGP checks fail, and users must manually
remove expired keys using commands like `rpmkeys --delete`.
The proposed solution is a new LIBDNF5 plugin. This plugin will act as
a hook, checking for invalid repository PGP keys on the system before
executing a DNF transaction.
* '''Interactive mode''': The plugin will prompt the user to confirm
the removal of each invalid key.
* '''Non-interactive mode''' (e.g., with `-y` or `--assumeno`): The
plugin will proceed automatically based on the specified user action,
either removing the keys or retaining them.
By default, this behavior will be enabled in DNF5, with the option to
disable it through configuration.
This enhancement stems from a request in
[https://github.com/rpm-software-management/dnf5/issues/1192 upstream
issue] and builds upon
[https://github.com/rpm-software-management/dnf-plugins-core/pull/533
the existing solution in DNF4]. Unlike DNF4's implementation, which is
not enabled by default, this change will be integral to the default
DNF5 functionality, aligning with its role as the primary package
manager in Fedora.
== Feedback ==
The proposed solution has been discussed with affected users,
including the Mock and Copr teams, as part of the discussions around
[https://github.com/rpm-software-management/dnf-plugins-core/pull/533
the existing solution in DNF4].
== Benefit to Fedora ==
This change enables the automatic management of repository keys during
software installation or upgrades.
== Scope ==
* Proposal owners:
** Implement a new LIBDNF5 plugin to manage repository PGP keys automatically.
* Other developers:
** No additional work identified at this time.
* Release engineering: [https://pagure.io/releng/issue/12477 #12477]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
No compatibility or upgrade issues expected.
== How To Test ==
A good reproducer is already described in
[https://github.com/rpm-software-management/dnf5/issues/1192#issuecomment-20…
this comment] within the upstream issue.
You can list all installed key hashes along with their names using:
`rpmkeys --list`
To query the key block info, use:
`rpm -q --qf "%{DESCRIPTION}" gpg-pubkey-<KEYHASH>` (note: `rpmkeys
--export <KEYHASH>` on newer RPM releases)
To get the end date in a human-readable format, run:
`rpm -q --qf "%{DESCRIPTION}" gpg-pubkey-<KEYHASH> | gpg --show-keys
--with-colon | cut -d':' -f7 | xargs -I{} date -d @{}
`
Note that not all keys have a defined end of validity date.
You can also try running a transaction using a COPR repository with
the `faketime` command from `libfaketime`:
`faketime '+10years' dnf install <pkg_name_from_copr>`
The above should fail without the functionality introduced by this
proposal. After deploying the new plugin, it should prompt the user
about the expired PGP key and ask for removal.
== User Experience ==
For interactive users, a prompt will appear informing them about each
outdated key on the system and asking for confirmation to remove it.
For non-interactive users, there will be no change to the workflow.
== Dependencies ==
No additional work is expected.
== Contingency Plan ==
* Contingency mechanism: Disable the new plugin from running by default.
* Contingency deadline: Fedora 42 branching from Rawhide
* Blocks release? No
== Documentation ==
The new behavior will be documented in the upstream DNF5 documentation.
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/DeprecatePamSshAgent
Discussion Thread -
https://discussion.fedoraproject.org/t/f42-change-proposal-deprecate-pam-ss…
This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes
process, proposals are publicly announced in order to receive
community feedback. This proposal will only be implemented if approved
by the Fedora Engineering Steering Committee.
== Summary ==
Drop pam_ssh_agent_auth component from Fedora 42
== Owner ==
* Name: [[User:Dbelyavs| Dmitry Belyavskiy]]
* Email: dbelyavs(a)redhat.com
== Detailed Description ==
pam_ssh_agent_auth is a subpackage of openssh developed separately.
Last years its development has effectively stopped and we are not
aware of it being used actively.
The goal of this proposal is to drop this package (as it will be done
in RHEL10) to reduce the maintenance burden.
== Feedback ==
== Benefit to Fedora ==
* Removing a package of limited use and maintenance
* Reducing the maintenance burden
== Scope ==
* Proposal owners: remove the corresponding files from OpenSSH package
* Other developers:
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
== Upgrade/compatibility impact ==
The users can still use this package from previous distributions if
they really need it.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? N
== How To Test ==
== User Experience ==
I expect the user experience effects to be minor because of quite
limited usage of this package
== Dependencies ==
None
== Contingency Plan ==
There are 2 relevant options:
* Return the previous state of the package
* build a more modern alternative, pam_rssh,
https://github.com/z4yx/pam_rssh, for Fedora
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
We drop pam_ssh_agent_auth module
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney