Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-dis…
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 ==
OpenSSL will no longer trust cryptographic signatures using SHA-1 by
default, starting from Fedora 41.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]]
* Email: asosedki(a)redhat.com
== Detailed Description ==
We would like to deprecate SHA-1 in signatures, because chosen-prefix
collision attacks on SHA-1 are becoming increasingly feasible.
Specifically, https://sha-mbles.github.io claims a complexity of
2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US
dollars by 2025 to find a chosen-prefix collision for a SHA-1
signature.
With this change accepted and implemented,
OpenSSL will start blocking SHA-1 signature creation and verification
by default.
The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]]
has previously included this change among several others.
This is a second attempt to propose it, two years later, with a narrower scope.
== Feedback ==
This change, when discussed as part of the rejected [[
Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]],
has proved itself controversial.
There seems to be a consensus that the change has to be done sooner or later,
but Fedora is a remarkably conservative distribution
when it comes to deprecating legacy cryptography, even if by-default-only.
The decision to discover code reliant on SHA-1 signatures
by blocking creation/verification has not gathered many fans,
but it's not like many viable alternative proposals have been raised
in return either.
In particular, there is no suitable facility to perform opt-out
logging of the deprecated operation.
Opt-in logging through USDT probes has been implemented the last time
and has been reinstated again to aid testing this change.
The precursor change has received limited testing during Fedora 37 Test Days,
with only a handful of bugs discovered.
The ones that were, though, wouldn't be something realistically
discoverable by other means.
The change has received significant testing in RHEL,
which distrusts SHA-1 signatures by default starting from RHEL-9.
Having this switch flipped in RHEL for ~2 years further enforces our
confidence in the change.
== Benefit to Fedora ==
Fedora's security defaults will inch closer to what is considered
secure in the modern-day cryptographic landscape.
== Scope ==
* Proposal owners: flip that switch in the DEFAULT policy, provide
transitional policies for testing the change.
* Other developers:
Test your applications under TEST-FEDORA41 policy.
If the security of your application depends on trusting SHA-1 signatures,
fix this, or it will stop working unless users explicitly opt into
lower security guarantees. See
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]].
* Release engineering: [https://pagure.io/releng/issue/12096 #12096]
A change is a runtime change, so the mass rebuild considerations
boil down to %check-time testsuite failures expecting different defaults.
Specifically, reverting the change can be safely done without a mass-rebuild.
* Policies and guidelines:
CryptoPolicies section of the packaging guidelines
will have to be updated to reflect that
SHA-1 signatures must not be trusted by default.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Community Initiatives:
== Upgrade/compatibility impact ==
The change is not expected to break upgrades themselves.
The ways people use Fedora are a multitude, and the rare scenarios
relying on trusting SHA-1 signatures will break.
Administrators willing to retain previous behavior and sacrifice security
will be able to apply a compatibility policy or subpolicy
before or after the upgrade.
== How To Test ==
Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`.
Proceed to use the system as usual,
identify the workflows which are broken by blocking SHA-1 signature
creation/verification,
ideally also verify that `update-crypto-policies --set DEFAULT` fixes them,
file bug reports against the affected components if not filed already.
Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `,
mention this change page, the version of crypto-policies package
and the policies under which your workflow does and does not work.
Alternatively, a tool to identify the affected operation without
blocking them will likely be provided,
installable from
https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer.
One would need openssl-3.2.1-9.fc41 or newer for the tool to work.
== User Experience ==
Some less-than-common use-cases will break.
(One example from Fedora 37 test days was interoperability with old
Apple devices).
The affected users will need to either explicitly opt into the
previous, less secure system configuration,
or wait until the affected packages are updated to move away from SHA-1.
Users that need the previous behaviour and don't mind the security
implications will be able to revert to the old behavior system-wide
(`update-crypto-policies --set FEDORA40`) or per-process (`runcp
FEDORA40 command args`, requires a
[https://copr.fedorainfracloud.org/coprs/asosedkin/crypto-policies-extras
copr-packaged] tool).
FEDORA40 policy will be maintained for several more Fedora releases.
== Dependencies ==
All reverse dependencies of openssl are potentially affected.
== Contingency Plan ==
* Contingency mechanism: the change is reverted
* Contingency deadline: Fedora 41 Beta Freeze
* Blocks release? Yes
Note: with the change being a flip of a switch at heart, there's not
much room for creativity in not completing it. Reverting is would be a
straightforward ordeal, and would not require a mass rebuild.
== Documentation ==
[[SHA1SignaturesGuidance | SHA1SignaturesGuidance]] contains relevant notes.
Fedora packaging guidelines should be modified accordingly.
== Release Notes ==
We'll need something to the tune of:
OpenSSL no longer trusts SHA-1 signatures are no longer trusted by default.
Affected users can opt out of the change at the expense of lowering
the system's security.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/RemoveIfcfgSupportInNM
Discussion Thread -
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 ==
Remove support for connection profiles stored in ifcfg format in NetworkManager.
== Owner ==
* Name: [[User:bengal| Beniamino Galvani]], [[User:ffmancera| Fernando
Fernández Mancera]], [[User:Till| Till Maas]]
* Email: <bgalvani(a)redhat.com>, <ferferna(a)redhat.com>, <till(a)fedoraproject.org>
== Detailed Description ==
NetworkManager supports different formats to persist connection
profiles to disk. The two formats currently in use in Fedora are
''keyfile'' and ''ifcfg''.
[https://networkmanager.dev/docs/api/latest/nm-settings-keyfile.html
Keyfile] is the native and preferred format. It supports all the
connection types and all the features.
[https://networkmanager.dev/docs/api/latest/nm-settings-ifcfg-rh.html
Ifcfg] is compatible with the old network-scripts. It only supports a
limited set of connection types, and it is
[https://lists.freedesktop.org/archives/networkmanager/2023-May/000103.html
deprecated] upstream.
This change proposal aims at removing NetworkManager support for ifcfg
files in Fedora. This is the last step of a process started several
releases ago:
* in Fedora 33, the default connection format was changed from ifcfg to keyfile;
* in Fedora 36, the plugin that handles ifcfg files was shipped in a
separate package and was not included in new installations;
* since Fedora 39, the NetworkManager daemon automatically migrates
ifcfg files to the keyfile format.
== Benefit to Fedora ==
Since ifcfg support is going to be removed upstream, it must also be
removed in Fedora. Keyfile is a valid and better replacement.
== Scope ==
* Proposal owners: drop the following packages:
** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin
** `NetworkManager-dispatcher-routing-rules` containing a dispatcher
script to apply routing rules in ifcfg format
** `NetworkManager-initscripts-updown` containing alternative
ifup/ifdown scripts compatible with initscripts commands, using
NetworkManager.
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
At this point no users should have connection profiles stored in ifcfg
format, as NetworkManager is automatically migrating them to keyfile
since Fedora 39.
According to [https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline
documentation] , system upgrades are supported only over 2 releases at
most (e.g. from 38 to 40); therefore, users upgrading to Fedora 41
must come from Fedora 39 or 40, which have the migration enabled.
If some users disabled the migration, they might still have ifcfg
files in `/etc/sysconfig/network-scripts`. A “readme-ifcfg-rh.txt”
file there warns users that the format is deprecated and is going to
be removed.
== How To Test ==
* Try to install the NetworkManager-initscripts-ifcfg-rh package
* The package is not available.
== User Experience ==
See the “Upgrade/compatibility impact” section.
== Dependencies ==
None
== Contingency Plan ==
* Contingency mechanism: Revert the change, try again the next Fedora release.
* Contingency deadline: Beta freeze
* Blocks release? no
== Documentation ==
No documentation change required.
== Release Notes ==
The change needs to be mentioned in the Release Notes.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-separate-package…
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 ==
Split <code>/usr/bin/dtrace</code> from
<code>systemtap-sdt-devel</code> ({{package|systemtap}}) into a
separate package to optimize many buildroots by removing unnecessary
Python dependencies.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbalhar(a)redhat.com
== Detailed Description ==
The package <code>systemtap-sdt-devel</code> currently contains header
files and the script <code>/usr/bin/dtrace</code>, which is written in
Python and uses pycparser. This results in unnecessary Python and
pycparser installations for many packages that do not need the script
(and many times Python at all), as they only require the header files.
Moreover, some important packages (like perl-devel) require
systemtap-sdt-devel which means hundreds of Perl packages have Python
installed in their buildroots because of the single script they don't
need.
The idea was tested on all packages build-requiring perl-devel but
don't build-requiring python-devel directly - 520 in total. And from
that number:
* 7 failed to build for unrelated reasons
* 3 packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
* 81 packages have python3-libs but not python3-devel (different
reasons than systemtap-sdt-devel)
and finally, the rest - 436 packages - builds fine without the Python
script in systemtap-sdt-devel and therefore without Python at all.
Further testing on packages directly requiring systemtap-sdt-devel
identified the following needing the dtrace script:
* glib2
* sssd
* qemu
* python2.7
* postgresql15
* postgresql16
* perl
* php
* mariadb10.11
* libvirt
Those will depend on a new package to which we move the script.
== Feedback ==
The proposal has been positively received on the
[https://lists.fedorahosted.org/archives/list/devel@lists.fedoraproject.org/…
Fedora devel list].
== Benefit to Fedora ==
By splitting the <code>/usr/bin/dtrace</code> script into a separate
package, we reduce the buildroot size and improve build times for
hundreds of packages that do not require Python.
== Scope ==
* Proposal owners:
# Move the script to a new package <code>systemtap-sdt-dtrace</code>
and update <code>systemtap-sdt-devel</code> to require this new
package for backward compatibility.
# Update affected packages to depend on <code>systemtap-sdt-dtrace</code>.
# Remove the backward-compatible requirement from
<code>systemtap-sdt-devel</code>.
* Other developers: Review and merge proposed changes, and report any bugs.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
Package maintainers can proactively prepare their packages after the
first step from the plan above is implemented. Failed builds
identifying packages requiring changes are available in
[https://copr.fedorainfracloud.org/coprs/lbalhar/sdt-devel-no-dtrace/
COPR].
Maintainers can also build and test their packages with the version of
systemtap-sdt-devel from which the script has been removed.
== User Experience ==
Regular distro users shouldn't notice any change.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Change owner will revert the change in
{{package|systemtap}}.
* Contingency deadline: N/A (not a System Wide Change) <!-- REQUIRED
FOR SYSTEM WIDE CHANGES -->
* Blocks release? N/A (not a System Wide Change) <!-- REQUIRED FOR
SYSTEM WIDE CHANGES -->
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOMEWorkstationMedia
Discussion Topic -
https://discussion.fedoraproject.org/t/f41-change-proposal-wayland-only-gno…
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 ==
Remove the GNOME X11 packages from the Fedora Workstation media. The
packages will remain available in the repositories maintained by the
GNOME SIG, but not preinstalled on the media anymore.
== Owner ==
* Name: [[User:Ngompa| Neal Gompa]]
* Email: ngompa13(a)gmail.com
== Detailed Description ==
As part of the upstream deprecation and effort to remove X11 support
from GNOME, Fedora Workstation media will no longer include the GNOME
X11 packages. The packages will remain in the repository (maintained
by the GNOME SIG/Workstation WG) for users to manually install at this
time.
== Feedback ==
== Benefit to Fedora ==
This aligns us with the effort going on upstream to deprecate and
retire the GNOME X11 session. It also partly aligns us with Fedora
KDE. Like the Fedora KDE SIG, the Fedora Workstation WG recommends and
supports the Wayland platform for graphics.
Fedora Workstation has a long history of developing and promoting the
Wayland experience for GNOME, and
[https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA it
has been the primary experience for all users (including those with
NVIDIA cards) since Fedora Linux 36]. This reaffirms our commitment to
the Wayland GNOME experience in furtherance of the goal to provide the
highest quality GNOME experience through Fedora Workstation.
== Scope ==
* Proposal owners: Drop the GNOME X11 packages from the GNOME groups
in comps and replace them with their Wayland counterparts. Pull
request: [https://pagure.io/fedora-comps/pull-request/972
pagureio#fedora-comps#972]
* Other developers: N/A (not needed for this Change)
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
Systems upgrading from older releases of Fedora Workstation will not
be impacted, as this only affects new installs.
== Early Testing (Optional) ==
Not applicable to this change.
== How To Test ==
Not applicable to this change, as we're only dropping a non-default
experience from the media.
== User Experience ==
Going forward until the X11 session packages are fully dropped, users
will need to manually install them from the repository if they need
it.
== Dependencies ==
Not applicable for this change.
== Contingency Plan ==
* Contingency mechanism: Revert the comps change
* Contingency deadline: Final freeze
* Blocks release? Yes.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
Fedora Workstation no longer pre-installs the deprecated GNOME X11
session for new installations. Users who wish to add it back can do so
by installing the <code>gnome-session-xsession</code> and
<code>gnome-classic-session-xsession</code> packages.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Hello,
To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated
rebuild in a side tag.
https://fedoraproject.org/wiki/Changes/Python3.13
Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024.
We hope to start the mass rebuild shortly after it's available.
TL;DR: If you can, for the period of the mass rebuild just don't build
your packages in rawhide.
We will let you know when the side tag rebuild actually starts and when
it is merged and it's safe to build in rawhide with Python 3.13.
Details:
If you see a "Rebuilt for Python 3.13" (or similar) commit in your package,
please don't rebuild it in regular rawhide or another rawhide side tag.
If you need to, please let us know, so we can coordinate.
If you'd like to build a package after we already rebuilt it, you should
be able to build it in the side tag via:
on branch rawhide:
$ fedpkg build --target=f41-python
$ koji wait-repo f41-python --build <nvr>
It takes time to build all the essential packages,
so don't expect all your dependencies to be available right away.
Any attempts to build your packages in the side tag before we do will
likely fail due to missing dependencies.
When in trouble, ask here or on Fedora's Matrix - Fedora Python room
(https://matrix.to/#/#python:fedoraproject.org)
Ping me (ksurma) or Miro (mhroncok) if you need to talk to us.
Builds will appear here:
https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&order=…
Please avoid any potentially disturbing or major changes in Python
packages until the rebuild is over.
Thanks!
Karolina
Wiki - https://fedoraproject.org/wiki/Changes/golang1.23
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-golang-1-23-syst…
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 ==
Update of Go (golang package) to the upcoming version 1.23 in Fedora 41.
== Owner ==
* Name: [[User:alexsaezm| Alejandro Sáez Morollón]]
* Email: asm(a)redhat.com
== Detailed Description ==
Update of Go (golang package) to the upcoming version 1.23 in Fedora
41. Go 1.23 is expected to be released in
[https://tip.golang.org/doc/go1.23 August 2024]. A mass rebuild of all
of the dependent packages is required.
== Feedback ==
No feedback yet.
There is an [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
ongoing conversation] about removing a patch and revert to the
defaults a couple of variables.
== Benefit to Fedora ==
Up-to-date and latest Go release will be delivered to Fedora users.
Being close to upstream allows us to avoid security issues and provide
more up-to-date features. Therefore, Fedora will be providing a
reliable development platform for the Go language and projects written
in it.
For a complete list of changes, see upstream change notes at
https://tip.golang.org/doc/go1.23
== Scope ==
* Proposal owners:
Rebase Golang package in Fedora 41, and help resolve possible issues
found during package rebuilds.
* Other developers:
Fix possible issues, with help from Golang maintainers.
* Release engineering: [https://pagure.io/releng/issues #Releng issue number]
Rebuild of dependent packages as part of planned mass-rebuild.
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy:
It doesn't align directly with the current objectives, but it helps
maintain the quality of the project.
== Upgrade/compatibility impact ==
No upgrade or compatibility impact.
== How To Test ==
# Install golang 1.23 from rawhide and use it to build your
application(s)/package(s).
# Perform a scratch build against rawhide.
# Your application/package built using golang 1.23 should work as expected.
== User Experience ==
Users will have a newer version of Go, with new features described in
the release notes and security fixes.
== Dependencies ==
<pre>
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'golang'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'compiler(go-compiler)'
dnf repoquery -q --releasever=rawhide --disablerepo='*'
--qf='%{name}' --enablerepo=fedora-source --enablerepo=updates-source
--enablerepo=updates-testing-source --archlist=src --whatrequires
'go-rpm-macros'
</pre>
<pre>
Omitted due to the number of packages listed: ~2000.
</pre>
== Contingency Plan ==
* Contingency mechanism: Revert to Go 1.22.X if significant issues are
discovered
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
https://tip.golang.org/doc/go1.23
== Release Notes ==
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/UnprivilegedUpdatesAtomicDesktops
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-unprivileged-upd…
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 ==
We want to update the Polkit rule currently controlling access to the
rpm-ostree daemon on Fedora Atomic Desktops to do the following:
* Enable users to update the system without being an administrator or
typing a password.
* Restrict the current rule for administrators to make more operations
explicitly require a password.
== Owner ==
* [[User:boredsquirrel| Henning]], boredsquirrel(a)secure.mailbox.org
* [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org
== Detailed Description ==
This change tries to address two issues:
* Give more users the permission to update their systems as this
should be an entirely safe operation on Fedora Atomic Desktops.
** Silverblue already automatically update the system and Flatpaks by
default and Kinoite is looking at doing it as well:
https://fedoraproject.org/wiki/Changes/KDEKinoiteAutoUpdateByDefault
** We will thus enable all active and interactive users to update the
system without being an administrator or typing a password.
** Note that this is only about system updates (and repo metadata
updates) and no other operations.
* Reduce access to the most privileged operations of rpm-ostree for
administrators to avoid mistakes.
** The current setup is not directly a security issue as it only
allows those operations for users that are part of the wheel group and
thus assumed to be administrators.
** However, some of those operations can be more dangerous than others
so we should ask the administrator to confirm them or let them do it
via `sudo`.
** Operations such as changing kernel arguments, installing a local
package, rebasing to another image, etc. will thus be removed from the
current Polkit rule and will now require the administrator password,
similarly to calling it via `sudo`.
** Only the install/uninstall packages from the repos, upgrade,
rollback, cancel and cleanup operations will remain password-less, to
match the behavior on package mode Fedora with dnf.
See:
* https://gitlab.com/fedora/ostree/sig/-/issues/7
* https://github.com/rohanssrao/silverblue-privesc/issues/4
* https://bugzilla.redhat.com/show_bug.cgi?id=2203555
Initial work in:
* https://src.fedoraproject.org/rpms/fedora-release/pull-request/324
* https://src.fedoraproject.org/rpms/fedora-release/pull-request/325
== Feedback ==
Nothing here so far beyond comments in the PRs, which have mostly been
addressed.
== Benefit to Fedora ==
This change will make it easier to setup a Fedora system with
non-administrator (unprivileged) users that can still update the
system without administrator intervention. Note that major version
upgrades (rebase operation) will still require privileges (or an
administrator password) for now. This is due to a limit of the current
rpm-ostree interface.
This is also a step towards the goals of the
[https://fedoraproject.org/wiki/SIGs/ConfinedUsers Confined Users
Special Interest Group (SIG)].
== Scope ==
* Proposal owners:
** Implement the change in the polkit rules
** Validate that this changes works on all Fedora Atomic Desktops
(notably with GNOME Software and Plasma Discover)
* Other developers:
** Developers depending on the current polkit rules might have to
adapt their software. We don't know of any software impacted right
now.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: Not specificaly
== Upgrade/compatibility impact ==
This change does not remove any interface so it should not have any
impact for users on upgrade. If some of the now "password-full"
operations were used previously, they will now ask for a password.
If administrators previously disabled or overwrote the current polkit
rules, then they might have to update their override for the new
behavior.
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? No
== How To Test ==
* Write the following file:
`/etc/polkit-1/rules.d/org.projectatomic.rpmostree1.rules`
<pre>
polkit.addRule(function(action, subject) {
if ((action.id == "org.projectatomic.rpmostree1.repo-refresh" ||
action.id == "org.projectatomic.rpmostree1.upgrade") &&
subject.active == true &&
subject.local == true) {
return polkit.Result.YES;
}
if ((action.id ==
"org.projectatomic.rpmostree1.install-uninstall-packages" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.reload-daemon" ||
action.id == "org.projectatomic.rpmostree1.cancel" ||
action.id == "org.projectatomic.rpmostree1.cleanup" ||
action.id == "org.projectatomic.rpmostree1.client-management") &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
if ((
action.id == "org.projectatomic.rpmostree1.install-local-packages" ||
action.id == "org.projectatomic.rpmostree1.override" ||
action.id == "org.projectatomic.rpmostree1.deploy" ||
action.id == "org.projectatomic.rpmostree1.rebase" ||
action.id == "org.projectatomic.rpmostree1.rollback" ||
action.id == "org.projectatomic.rpmostree1.bootconfig" ) &&
subject.active == true &&
subject.local == true &&
subject.isInGroup("wheel")) {
return polkit.Result.AUTH_ADMIN;
}
});
</pre>
* Test that normal / unprivileged users can '''only do''' the
following operations '''without a password''':
** Update the system: `rpm-ostree update`
** Refresh the metadata: `rpm-ostree refresh-md`
* Test that admin / privileged users can do the following operations
'''without a password''':
** Install a package from the official Fedora repos: `rpm-ostree install strace`
** Cancel an in-progress transaction: `rpm-ostree cancel`
** Rollback to a previous version: `rpm-ostree rollback`
** Reload the daemon: `rpm-ostree reload`
** Cleanup pending or rollback deployments: `rpm-ostree cleanup`
* Test that admin / privileged users are '''asked a password''' for
the following operations:
** Install a local RPM package: `rpm-ostree install ./foo.rpm`
** Override replace a package: `rpm-ostree override replace vim-x.y.z.rpm`
** Deploy a specific version: `rpm-ostree deploy 40.20240518.1`
** Rebase to any version: `rpm-ostree rebase ...` (try with Kinoite on
Silverblue, etc.)
** Change kernel argments: `rpm-ostree kargs --append=foo=bar`
== User Experience ==
This change should be mostly transparent for users.
If some of the now "password-full" operations were used previously,
they will now ask for a password.
Unprivileged users will be able to update the system.
== Dependencies ==
The rules are shipped as part of the `fedora-release` RPM. There are
no other dependencies.
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?)
** We can revert the change to the `fedora-release` package at any time.
** Will be done by the change owners.
* Contingency deadline: Beta freeze or final freeze
* Blocks release? No
== Documentation ==
No additional documentation.
== Release Notes ==
To be written once the change is accepted.
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney
Wiki - https://fedoraproject.org/wiki/Changes/TunedAsTheDefaultPowerProfileManagem…
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-make-tuned-the-d…
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 ==
This Change makes ‘tuned’ the default power profile management daemon
in Fedora Workstation, KDE Plasma, and Budgie instead of
power-profiles-daemon.
* tuned-ppd provides a drop-in replacement for power-profiles-daemon,
which allows it to be used with current desktops
* power users can customize the desktop-exposed power profiles by
editing /etc/tuned/ppd.conf
== Owner ==
* Name: [[User:smallorange| Kate Hsuan]], [[User:jskarvad | Jaroslav Škarvada]]
* Email: <hpa(a)redhat.com>, <jskarvad(a)redhat.com>
== Detailed Description ==
<p>
Tuned and power-profiles-daemon provide a similar function to set and
tune the power status of a system. Both of them have similar features,
if they can be integrated into one, it allows the Fedora user to have
more options for power settings of their system and benefits the
users. In this proposal, we set up tuned to the default power profile
management daemon for the GNOME in Fedora Workstation and the KDE
Plasma Spin. Tuned already provides power profiles for different use
cases. Recently, tuned released the translation API layer called
tuned-ppd which can translate the power-profiles-daemon API to tuned.
The applications that use power-profiles-daemon API can access tuned
without modifying the code. For now, the Fedora user can immediately
switch to tuned by installing the tuned-ppd package without impacting
the user experience. Therefore, tuned can be the default power profile
management daemon for Fedora.
</p>
<p>
This work would replace power-profiles-daemon with tuned. Since tuned
already provides a wide range of power profiles for different
purposes, this allows the user to have more options for configuring
the system power profile.
Tuned provides many kinds of advanced and basic profiles for different
purposes. Power-profiles-daemon provides the basic power profiles and
the profiles can be set to the system through platform_profiles, Intel
p-state and AMD p-state. That is simple and clever. However, if the
users want to ask for an advanced profile, they need to install
another power utility, such as tuned to fine-tune their system. With
tuned as the default power profile management daemon, users have a
wider range of profiles to fine-tune the system.
</p>
<p>
Tuned released a new translation API service called tuned-ppd
<ref>https://github.com/redhat-performance/tuned/tree/master/tuned/ppd</ref>.
tuned-ppd can translate the power-profiles-daemon API to the tuned API
so applications can talk with tuned without modification. Moreover,
the GUI settings, such as gnome-control-center can configure tuned
profiles through tuned-ppd. tuned-ppd also allows the user to override
the basic three power profiles, including power-saver, balanced, and
performance through the config file /etc/tuned/ppd.conf
<ref>https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf</ref>.
If the user wants to use a customized profile, they can edit the
config file and map the custom profile to the basic three
power-profiles-daemon profile names. In this way, gnome-control-center
can keep the original design to configure the customized profile.
</p>
<p>
The work expects tuned to replace the power-profiles-daemons to offer
a wider range of power profiles to Fedora users. tuned-ppd resolved
the API translation issue so the application can access tuned service
through power-profiles-daemon API without converting to the tuned API.
Moreover, the three basic profiles can be overridden when the user
needs it for their use case. It also benefits GNOME applications that
can keep the original design and designing a new GUI tool for custom
profiles is unnecessary. Therefore, tuned can be the default power
setting service for Fedora.
</p>
== Feedback ==
'''From fedora-devel'''
<p>
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
1. The dependency concern. Since tuned is written by Python, that
causes a dependency impact on Fedora installation.
2. The power-profiles-daemon API should be ported to tuned to provide
the function to the application that uses power-profiles-daemon API,
such as gnome-shell and gnome-control-center.
</p>
'''From the hardware vendor'''
<p>
Moreover, we discuss it with vendors through the mail.
1. Since tuned covers several kinds of system tuning schemes that
allow the vendor to implement their power profile for different
devices or workloads. For power-profile-daemon, it only has three
profiles to set and every detail setting should be done through the
firmware level. If tuned can replace power-profiles-daemon, they can
imagine they can develop the profile in a much more flexible manner.
</p>
'''The previous discussions'''
<p>
https://discussion.fedoraproject.org/t/f40-change-proposal-tuned-replaces-p…
</p>
== Benefit to Fedora ==
<p>
<ol>
<li>Benefits the user. The user would have more options to tune their
system.</li>
<li>Benefits the maintainer. Integrate similar software into one
software to reduce the maintenance effort.</li>
</ol>
</p>
== Scope ==
* Proposal owners:
** for GNOME: update gnome-control-center weak dependency on
power-profile-daemon to tuned-ppd
** for KDE: update powerdevil weak dependency on power-profile-daemon
to tuned-ppd
** for Budgie: update budgie-control-center weak dependency on
power-profile-daemon to tuned-ppd
* 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 ==
<p>
Since tuned-ppd provides the ppd APIs and features, there is no impact
on other applications.
</p>
== Early Testing (Optional) ==
Do you require 'QA Blueprint' support? Y/N
== How To Test ==
<ol>
<li>
Remove power-profiles-daemon.<br>
$ sudo dnf remove power-profiles-daemon
</li>
<li>Install tuned and tuned-ppd through the following command<br>
$ sudo dnf install tuned<br>
$ sudo dnf install tuned-ppd
</li>
<li>
Run gnome-control-center and switch to the power panel and then select
one of the three power profiles.
Click the top-right corner of the screen and you can see the “Power
Mode” shows the profile name that you selected previously.
</li>
<li>
Run the following command to show the active profile. Since tuned-adm
shows the tuned profile name, the profile name mapping can be found in
/etc/tuned/ppd.conf.<br>
$ tuned-adm active
</li>
</ol>
== User Experience ==
<ol>
<li>
The workstation user can set the power profile through the gnome-control-center.
</li>
<li>
The server users switch the profile through the tuned command line.
</li>
</ol>
== Dependencies ==
<p>
tuned is written by Python so it depends on python packages and its 40 packages.
</p>
== Contingency Plan ==
* Contingency mechanism:
<p>
Use the original power-profiles-daemon
</p>
* Contingency deadline:
<p>
Before F41 beta freeze.
</p>
* Blocks release?
<p>
No, tuned-ppd provides all the power-profiles-daemon APIs otherwise
the original power-profile-daemon can be used when the plan blocks the
release.
</p>
== Documentation ==
I have talked with tuned about this information.<br>
https://github.com/redhat-performance/tuned/issues/559
== Release Notes ==
* https://github.com/redhat-performance/tuned/tree/master/tuned/ppd
* https://github.com/redhat-performance/tuned/blob/master/tuned/ppd/ppd.conf
--
Aoife Moloney
Fedora Operations Architect
Fedora Project
Matrix: @amoloney:fedora.im
IRC: amoloney