F36 Change: Keylime subpackaging and agent alternatives
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Keylime_subpackaging_and_agent_alt...
== Summary ==
The [https://src.fedoraproject.org/rpms/keylime keylime] package will
be split into subpackages per role (agent, registrar, verifier, and
admin components), while allowing the alternative agent implementation
in Rust.
== Owner ==
* Name: [[User:Scorreia| Sergio Correia]]
* Email: scorreia(a)redhat.com
* Name: [[User:Ueno| Daiki Ueno]]
* Email: dueno(a)redhat.com
== Detailed Description ==
The current [https://keylime.dev/ Keylime] package available in Fedora
provides all the components as a single package. To support the usage
scenarios where only agent or management component is deployed on a
specific host, we plan to split the package into subpackages per role.
This change also enables the alternative Keylime agent implementation
in Rust, which will eventually be preferred over the Python
implementation.
== Benefit to Fedora ==
This makes it easier to deploy Keylime agent in IoT or Fedora CoreOS
spins and thus enable remote attestation without installing full
dependencies of Keylime.
== Scope ==
* Proposal owners:
** The keylime package will provide subpackages (keylime-agent,
keylime-registrar, etc)
** The keylime package will be a meta package that will install all
the subpackages
** The Rust based [https://github.com/keylime/rust-keylime agent] will
be packaged along with its build dependencies
** Both keylime-agent implementations, one written in Python, the
other written in Rust, will be selectively installable through
[https://docs.fedoraproject.org/en-US/packaging-guidelines/Alternatives/
alternatives] or a similar mechanism
* Other developers: N/A (not a System Wide Change)
* Release engineering: [https://pagure.io/releng/issues #Releng issue
number] N/A (not a System Wide Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
The keylime package will remain as a meta package for the
compatibility with the current packaging.
== How To Test ==
# Make sure that your systems meet the requirement to run either
Keylime agent or other components, as described in the
[https://keylime-docs.readthedocs.io/en/latest/ documentation]
# Install the subpackages individually and see if they function as expected
# Install the meta package (keylime) and see if it pulls all the subpackages
# Selectively install a package that provides the keylime-agent
functionality: either rust-keylime_agent (Rust-based) or
(python-)keylime-agent (Python-based), and see if they do not
interfere with each other
# If alternatives is used, check that both packages can simultaneously
exist on the same system and the user can switch the implementation
with the alternative --set command
== User Experience ==
No visible change should be observed by the existing users.
== Dependencies ==
N/A (not a System Wide Change)
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* Contingency deadline: N/A (not a System Wide Change)
* Blocks release? No
== Documentation ==
N/A (not a System Wide Change)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: GHC compiler parallel version installs (Self-Contained
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GHC_parallel_version_installs
== Summary ==
Introduce ghcX.Y packages to Fedora which can be parallel installed,
in addition to the main ghc package.
== Owner ==
* Name: [[User:Petersen|Jens Petersen]]
* Email: petersen(a)redhat.com
== Detailed Description ==
Currently ghc modules are available in Fedora but they cannot be
installed in parallel.
This Change will enable being able to easily install multiple versions
of ghc in parallel,
which can be useful for development - both for working on different projects
and testing projects for compatibility across different ghc versions.
== Feedback ==
This was proposed to the Fedora Haskell mailing list already and so
far there were no objections.
== Benefit to Fedora ==
Parallel installs of ghc versions will allow more flexible Haskell
development using Fedora Linux.
== Scope ==
* Proposal owners:
** update ghc-rpm-macros to support the packaging [done]
** add ghc9.2 [built for rawhide]
** add ghc9.0 [repo created]
** add ghc8.10 [may not be needed for F36]
** add ghc8.8 [stretch goal]
** add cabal-install3.4 and/or cabal-install3.6 [stretch goal]
** also backport ghcX.Y's to F35, F34, and EPEL
* Other developers: N/A
* Release engineering: N/A
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
These are new packages so upgrading from older releases should be fine.
Eventually future Fedora version upgrades will probably need to
obsolete very old ghcX.Y versions.
== How To Test ==
1. dnf install ghc ghc9.2 ghc9.0
== User Experience ==
Installing ghc, ghc9.0, and ghc9.2 will give you /usr/bin/ghc,
/usr/bin/ghc-9.0.x and /usr/bin/ghc-9.2.x.
Their Haskell libraries will have ghc versioned directories and .so files.
== Dependencies ==
N/A
== Contingency Plan ==
* Contingency mechanism: (What to do? Who will do it?) N/A (not a
System Wide Change)
* 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 ==
With the introduction of versioned ghcX.Y packages multiple versions
of the Haskell GHC compiler can now be installed parallel in the
Fedora Linux.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F35 election results
by Ben Cotton
Greetings, all!
The elections for the Fedora Linux 35 cycle have completed.
## Fedora Council
Tom Callaway is re-elected to the Fedora Council
## Fedora Engineering Steering Committee (FESCo)
The following candidates are elected to FESCo:
* Miro Hrončok
* Kevin Fenzi
* Zbigniew Jędrzejewski-Szmek
* Fabio Valentini
* David Cantrell
Additionally, Tom Stellard is elected to a half-term to fill the seat
vacated by Dan Čermák.
## Fedora Mindshare Committee
Till Maas is re-elected to the Fedora Mindshare Committee.
Congratulations to all those elected and thank you to the candidates
and voters. I am out of the office on Friday, so I'll make the
appropriate documentation and permissions updates on Monday.
For more details, visit the Community Blog post:
https://communityblog.fedoraproject.org/fedora-linux-35-election-results/
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: Wayland By Default with NVIDIA proprietary Driver
(System-Wide Change)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA
== Summary ==
Enable Wayland sessions by default in GDM even with the NVIDIA
proprietary driver.
== Owner ==
* Name: [[User:ofourdan| Olivier Fourdan]]
* Email: <ofourdan(a)redhat.com>
== Detailed Description ==
Recent updates in NVIDIA proprietary driver allow Xwayland to benefit
from hardware acceleration and X11 applications can have their
rendering hardware accelerated.
That allowed to enable Wayland sessions even when the NVIDIA
proprietary driver is used, but keeping Xorg the default in that case.
This proposal is to make Wayland by default with newer versions of the
NVIDIA proprietary driver to remain consistent with other drivers.
GDM already has a set of udev rules which check for the driver and its
version, so this would only require a tweak in the udev rules to make
Wayland session the default with the next version of the NVIDIA driver
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in].
Note that currently Xorg is also preferred in the case of multiple
GPU, this would remain the case with this proposal.
This change is just about changing the default with NVIDIA proprietary
driver on supported configurations, “GNOME on Xorg” still remains an
option, just like with other drivers.
== Benefit to Fedora ==
Fedora has changed to Wayland by default since [[Changes/Login Screen
Over Wayland|Fedora 22]], but the NVIDIA proprietary driver has been
an exception ever since (either because originally Wayland would be
disabled with NVIDIA drivers, or more recently Xorg would be used by
default).
Currently, when first installing Fedora on NVIDIA hardware, users get
Wayland by default with the Open Source "nouveau" driver, with Xorg
being an option in the login screen. If they later decide to enable
the rpmfusion repository and install the NVIDIA proprietary driver,
they get Xorg by default and Wayland as an option.
This change would make the default consistent regardless of the
driver, for single GPU systems.
== Scope ==
* Proposal owners: Tweak the gdm udev rule to enable Wayland with the
NVIDIA proprietary driver above a given version
[https://gitlab.gnome.org/GNOME/gdm/-/blob/main/data/61-gdm.rules.in#L7-17]
* Other developers: [[User:Rstrode| Ray Strode]] for reviewing the
changes in the udev rules from GDM
* Release engineering: This change doesn't affect release workflow
* Policies and guidelines: This change doesn't affect packaging guidelines
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: No
== Upgrade/compatibility impact ==
== How To Test ==
# Requires an NVIDIA GPU supported by the recent NVIDIA proprietary
driver and `nvidia-drm.modeset=1` set in the kernel command line to
enable KMS [http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html]
(rpmfusion packages for the NVIDIA driver do that automatically)
# Enable the rpmfusion “nonfree” repository to install the NVIDIA
graphics drivers
[https://docs.fedoraproject.org/en-US/quick-docs/setup_rpmfusion/]
# Install the NVIDIA proprietary driver (and the
`xorg-x11-drv-nvidia-power` package for suspend/resume support - see
[https://rpmfusion.org/Howto/NVIDIA?highlight=%28%5CbCategoryHowto%5Cb%29#...]
and [http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/powerman...]
for more details) from the rpmfusion repository
# Reboot the machine
# Ensure graphical login screen comes up
# Try to log into a "GNOME" session
# Check whether this is a "GNOME on Wayland" session (both `$DISPLAY`
and `$WAYLAND_DISPLAY` are set)
# Log out
# Try to log into a "GNOME on Xorg" session
# Check whether this is a "GNOME on Xorg" session (`$DISPLAY` is set,
`$WAYLAND_DISPLAY` is not set)
== User Experience ==
Users with NVIDIA hardware and NVIDIA proprietary driver installed
will get a Wayland session by default when selecting the "GNOME"
session in the login screen.
== Dependencies ==
This depends on the NVIDIA proprietary driver and its support for Wayland.
Typically, this proposal would change the default in a future version
of the NVIDIA driver which is not released yet.
== Contingency Plan ==
* Contingency mechanism: Revert the default to Xorg for NVIDIA driver
by reverting the changes in the udev rule shipping with GDM
* Contingency deadline: Beta Freeze
* Blocks release? No
== Documentation ==
NVIDIA's own documentation
[http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/]:
* http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/kms.html
* http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/xwayland...
* http://us.download.nvidia.com/XFree86/Linux-x86_64/495.44/README/gbm.html
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: Make Rescue Mode Work With Locked Root (System-Wide
Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FixRescueMode
== Summary ==
Fedora defaults to locking the root account, which is needed by
single-user mode. This Change uses `sulogin --force` so the password
request is bypassed under this circumstance.
== Owner ==
* Name: [[User:Salimma|Michel Alexandre Salim]]
* Email: michel(a)michel-slm.name
* Name: [[User:Ngompa|Neal Gompa]]
* Email: ngompa13(a)gmail.com
* Name: [[User:Davdunc|David Duncan]]
* Email: davdunc(a)amazon.com
== Detailed Description ==
Users typically only use single-user mode in case the normal boot is
not working. In the unfortunate situation that it happens, under the
current setup they cannot recover without booting from a Fedora live
image or another image, or by overriding `init=`, because our
single-user mode requires a root password, and by default we lock the
root account.
A more user-friendly setup is to allow the password to be bypassed in
case it's not set.
This does not pose an increased security risk:
- you can already boot with `init=/sysroot/bin/bash` anyway
- anyone with physical access to a machine can probably compromise it
- you can enforce the need for a root password in single-user mode by setting it
This change will be implemented by pre-installing an RPM containing
systemd overrides for `emergency.service` and `rescue.service`,
similar to the [https://github.com/coreos/fedora-coreos-config/commit/eb74f2ea3e9b4539023...
CoreOS implementation], so users and editions/variants can opt out by
removing this or omitting it from their default installation.
== Benefit to Fedora ==
This Change provides a better out-of-the-box user experience in case
they need to rescue their system, by making the rescue option
presented in the bootloader actually work.
== Scope ==
* Proposal owners: Ship the needed configuration change in a systemd
subpackage. Test and verify that it works, then work with editions and
spins to test and enable this by default by making `systemd`
`Recommends: (systemd-rescue-defaults if dracut-config-rescue)`
* Other developers: Test this and opt-out if necessary (eg cloud
doesn't have a rescue initramfs so the package is deadweight). On
variants where dracut-config-rescue is installed but an opt out is
desired, excluding the package from installation will prevent it being
installed on systemd upgrades
* Release engineering: [https://pagure.io/releng/issue/10422 #10422]
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A
== Upgrade/compatibility impact ==
Upgrades would pull in this automatically, see
[https://fedoraproject.org/wiki/Changes/ExcludeFromWeakAutodetect]
== How To Test ==
- `dnf install systemd-rescue-defaults`
- reboot and verify rescue mode works
== User Experience ==
Rescue mode works out of the box, without resorting to overriding
init= or using a live media.
== Dependencies ==
- most changes will be done in the `systemd` package
- for variants that need to opt out we'll need to modify their kickstart files
== Contingency Plan ==
* Contingency mechanism: if the `Recommends` have been added to
systemd, remove it and potentially add an `Obsoletes:` to remove older
known-bad versions of `rescue-defaults`
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
The built-in rescue mode now works out of the box without needing to
use a live image. For added security you can set a root password.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
Orphaned packages looking for new maintainers
by Miro Hrončok
The following packages are orphaned and will be retired when they
are orphaned for six weeks, unless someone adopts them. If you know for sure
that the package should be retired, please do so now with a proper reason:
https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life
Note: If you received this mail directly you (co)maintain one of the affected
packages or a package that depends on one. Please adopt the affected package or
retire your depending package to avoid broken dependencies, otherwise your
package will fail to install and/or build when the affected package gets retired.
Request package ownership via the *Take* button in he left column on
https://src.fedoraproject.org/rpms/<pkgname>
Full report available at:
https://churchyard.fedorapeople.org/orphans-2021-12-06.txt
grep it for your FAS username and follow the dependency chain.
For human readable dependency chains,
see https://packager-dashboard.fedoraproject.org/
For all orphaned packages,
see https://packager-dashboard.fedoraproject.org/orphan
Package (co)maintainers Status Change
================================================================================
Java-WebSocket orphan 4 weeks ago
PyPAM orphan, tmraz 3 weeks ago
apache-rat mizdebsk, orphan 0 weeks ago
arduino-ctags orphan 4 weeks ago
asl orphan 4 weeks ago
bytelist lef, orphan 4 weeks ago
chaos-client go-sig, orphan 4 weeks ago
chck fale, orphan, zvetlik 4 weeks ago
concurrent-trees hhorak, orphan 4 weeks ago
conky-manager orphan 4 weeks ago
couchdb orphan 4 weeks ago
crlfuzz go-sig, orphan 4 weeks ago
direvent orphan 1 weeks ago
dummy-test-package-rubino asaleh, orphan, packagerbot, 4 weeks ago
patrikp, scoady, wwoods
erlang-exometer_core orphan 4 weeks ago
erlang-protobuffs orphan 4 weeks ago
erlang-riak_api bowlofeggs, erlang-maint-sig, 4 weeks ago
orphan
erlang-riak_core bowlofeggs, erlang-maint-sig, 4 weeks ago
orphan
erlang-triq orphan 4 weeks ago
fennel epel-packagers-sig, lua- 4 weeks ago
packagers-sig, orphan
gdata-sharp moezroy, orphan, tpokorra 4 weeks ago
gnu-getopt dwalluck, mizdebsk, orphan 4 weeks ago
golang-github-beevik-ntp go-sig, orphan 4 weeks ago
golang-github-ema-qdisc go-sig, orphan 4 weeks ago
golang-github-mdlayher-wifi go-sig, orphan 4 weeks ago
golang-github-soundcloud-runit go-sig, orphan 4 weeks ago
icedtea-web jvanek, omajid, orphan 0 weeks ago
javadocofflinesearch orphan 1 weeks ago
js-termynal orphan 0 weeks ago
jsap orphan 4 weeks ago
kexi kde-sig, orphan 2 weeks ago
komparator orphan 4 weeks ago
latex-mk orphan 4 weeks ago
libgaiagraphics orphan 4 weeks ago
librfid orphan 4 weeks ago
mingw-colord-gtk gnome-sig, orphan 4 weeks ago
naabu go-sig, orphan 4 weeks ago
netcf berrange, orphan 5 weeks ago
nuclei go-sig, orphan 4 weeks ago
oci-kvm-hook orphan 4 weeks ago
pam_mount lupinix, orphan, steve 4 weeks ago
passenger kanarip, orphan 4 weeks ago
perl-OpenOffice-UNO filabrazilska, orphan, scenek 4 weeks ago
plantuml gil, orphan 2 weeks ago
plasma-applet-redshift-control kde-sig, lupinix, orphan 4 weeks ago
postgres-decoderbufs fjanus, hhorak, orphan, 4 weeks ago
panovotn
python-bsddb3 orphan 1 weeks ago
python-flask-compress orphan 1 weeks ago
python-productivity orphan 1 weeks ago
qwtpolar orphan 4 weeks ago
rubygem-simple-navigation orphan 4 weeks ago
rubygem-six orphan 4 weeks ago
rust-ruma-events orphan, rust-sig 4 weeks ago
rust-signature orphan 1 weeks ago
seahorse-sharing gnome-sig, orphan, stefw 4 weeks ago
shuffledns go-sig, orphan 4 weeks ago
sugar-visualmatch orphan 4 weeks ago
trafshow orphan 4 weeks ago
uddi4j galileo, orphan 0 weeks ago
umph orphan 3 weeks ago
vanessa_logger orphan 4 weeks ago
vgrive orphan 4 weeks ago
wsdl4j akurtakov, mizdebsk, orphan 0 weeks ago
wsil4j galileo, orphan 0 weeks ago
wxpdfdoc orphan 5 weeks ago
xfce4-equake-plugin cheese, orphan 4 weeks ago
yecht orphan 4 weeks ago
yydebug orphan 4 weeks ago
The following packages require above mentioned packages:
Report too long, see the full version at
https://churchyard.fedorapeople.org/orphans-2021-12-06.txt
See dependency chains of your packages at
https://packager-dashboard.fedoraproject.org/
See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan
Affected (co)maintainers (either directly or via packages' dependencies):
abbra: wsdl4j
akien: wsdl4j
akurtakov: wsdl4j
alexlan: wsdl4j
ankursinha: python-bsddb3
asaleh: dummy-test-package-rubino
avsej: wsdl4j
benc: python-bsddb3
berrange: netcf
bowlofeggs: erlang-riak_api, erlang-protobuffs, erlang-triq,
erlang-exometer_core, erlang-riak_core
brouhaha: wsdl4j
bruno: wsdl4j
cdorney: wsdl4j
cfu: wsdl4j
cheese: wsdl4j, xfce4-equake-plugin
cicku: python-bsddb3, wsdl4j
cipherboy: wsdl4j
ckelley: wsdl4j
codeblock: erlang-protobuffs, erlang-triq
coolsvap: wsdl4j
csutherl: wsdl4j
davidsch: python-bsddb3
deji: python-bsddb3, wsdl4j
dmoluguw: wsdl4j
dominik: wsdl4j
dwalluck: gnu-getopt
dwrobel: plantuml, wsdl4j
eclipseo: golang-github-ema-qdisc, wsdl4j, golang-github-beevik-ntp,
golang-github-mdlayher-wifi, golang-github-soundcloud-runit
edewata: wsdl4j
epel-packagers-sig: fennel
erlang-maint-sig: erlang-riak_api, erlang-protobuffs, erlang-triq,
erlang-exometer_core, erlang-riak_core
fab: wsdl4j
fale: chck
filabrazilska: erlang-protobuffs, perl-OpenOffice-UNO, erlang-triq
fjanus: postgres-decoderbufs
fnux: erlang-protobuffs, erlang-triq
fsimonce: wsdl4j
fujiwara: wsdl4j
galileo: wsil4j, uddi4j, wsdl4j
gil: plantuml
gnome-sig: seahorse-sharing, mingw-colord-gtk
go-sig: nuclei, crlfuzz, shuffledns, golang-github-ema-qdisc, chaos-client,
golang-github-beevik-ntp, golang-github-mdlayher-wifi, naabu,
golang-github-soundcloud-runit
grahamwhiteuk: python-bsddb3
greghellings: wsdl4j
gzaronikas: wsdl4j
helloworld1: wsdl4j
hhorak: postgres-decoderbufs, concurrent-trees
hubbitus: vanessa_logger
huwang: wsdl4j
icheishvili: erlang-protobuffs, erlang-triq
ignatenkobrain: rust-ruma-events
jcline: erlang-protobuffs, erlang-triq
jdekloe: python-bsddb3
jeckersb: erlang-protobuffs, erlang-triq
jerboaa: wsdl4j
jfearn: wsdl4j
jjames: python-bsddb3
jjelen: wsdl4j
jkastner: python-bsddb3
jmagne: wsdl4j
jorton: wsdl4j
jspaleta: python-bsddb3
jvanek: icedtea-web
jwrdegoede: wsdl4j
kanarip: passenger
kde-sig: plasma-applet-redshift-control, kexi
kwright: wsdl4j
laxathom: wsdl4j
leamas: jsap
lef: wsdl4j, python-bsddb3, bytelist
liangsuilong: wsdl4j
limb: python-bsddb3, wsdl4j
linkdupont: wsdl4j
lkundrak: erlang-protobuffs, erlang-triq, wsdl4j
lua-packagers-sig: fennel
lupinix: pam_mount, plasma-applet-redshift-control
martinlanghoff: erlang-protobuffs, erlang-triq
mharmsen: wsdl4j
mizdebsk: gnu-getopt, apache-rat, wsdl4j
mlichvar: wsdl4j
moceap: wsdl4j
moezroy: gdata-sharp
mskalick: wsdl4j
neuro-sig: python-bsddb3
nonamedotc: python-bsddb3
nphilipp: wsdl4j
omajid: wsdl4j, icedtea-web
packagerbot: dummy-test-package-rubino
panovotn: postgres-decoderbufs, wsdl4j
patrikp: dummy-test-package-rubino
pcpa: wsdl4j
peter: wsdl4j, erlang-protobuffs, erlang-triq, erlang-exometer_core,
erlang-riak_core
plautrba: python-bsddb3
pwalter: wsdl4j
pwu: wsdl4j
python-sig: python-bsddb3
qulogic: python-bsddb3
rjones: wsdl4j
rlandmann: wsdl4j
rmattes: wsdl4j
rust-sig: rust-ruma-events
s4504kr: erlang-protobuffs, erlang-triq, wsdl4j
sagitter: wsdl4j
scenek: perl-OpenOffice-UNO
scoady: dummy-test-package-rubino
sergiopr: python-bsddb3
skottler: erlang-protobuffs, erlang-triq
smani: wsdl4j, libgaiagraphics
spike: wsdl4j
spot: wsdl4j
stefw: seahorse-sharing
steve: pam_mount
teuf: wsdl4j
timn: wsdl4j
tkorbar: wsdl4j
tmraz: PyPAM
tomh: wsdl4j
tpokorra: gdata-sharp
ttorling: wsdl4j
vakwetu: wsdl4j
van: wsdl4j
verdurin: wsdl4j
volter: python-bsddb3
wwoods: dummy-test-package-rubino
xavierb: erlang-protobuffs, erlang-triq
zvetlik: chck
--
The script creating this output is run and developed by Fedora
Release Engineering. Please report issues at its pagure instance:
https://pagure.io/releng/
The sources of this script can be found at:
https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py
2 years, 4 months
F36 Change: Switch GnuTLS to allowlisting (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/GnutlsAllowlisting
== Summary ==
Presently, crypto-policies controls GnuTLS in a way that
"hard-disables" select algorithms, leaving no option for the
applications using GnuTLS to reenable said algorithms back. We propose
switching to more future-proof allowlisting-based configuration method
and offering API within GnuTLS to loosen the system defaults for
specific processes.
== Owner ==
* Name: [[User:Asosedkin| Alexander Sosedkin]], [[User:ueno|Daiki Ueno]]
* Email: asosedki(a)redhat.com
== Detailed Description ==
crypto-policies is an abstraction layer to enable centralized
configuration of system-wide cryptographic defaults across different
applications and libraries.
Presently, crypto-policies controls GnuTLS back-end using a
configuration file that starts from GnuTLS internal defaults (NORMAL)
and further blocks specific algorithms from it:
[overrides]
insecure-hash = SHA1
insecure-hash = MD5
...
disabled-version = DTLS1.0
[priorities]
SYSTEM=NORMAL
This approach has the following identified downsides:
1. Developers of applications using GnuTLS cannot override the
restrictions put in place by crypto-policies
(examples for such demand:
https://bugzilla.redhat.com/show_bug.cgi?id=1960763,
https://pagure.io/fesco/issue/2659),
turning them from a defaults to a hard cap on the set of algorithms.
2. Algorithms that will be implemented in future GnuTLS releases will
have to require a synchronized update with crypto-policies or risk
being inadvertently enabled.
Same applies to removing algorithms from GnuTLS NORMAL.
An alternative allowlisting-based configuration method and a matching
GnuTLS API extension to control it currently under development:
https://gitlab.com/gnutls/gnutls/-/merge_requests/1427. The change
will turn the interface upside-down, explicitly allowlisting trusted
algorithms:
[global]
override-mode = allowlist
[overrides]
secure-hash = SHA256
secure-hash = SHA384
...
enabled-version = DTLS1.2
[priorities]
SYSTEM=NONE
and offering an interface to control the restrictions both ways with new API:
int gnutls_protocol_mark_enabled(gnutls_protocol_t version);
int gnutls_protocol_mark_disabled(gnutls_protocol_t version);
We'd like to announce our intention to bring this change into Fedora 36.
== Feedback ==
The authors of the document don't have enough external feedback to the
change, presumably because, in theory, it is limited to the internal
interface between crypto-policies and gnutls.
== Benefit to Fedora ==
It will be possible for the applications using GnuTLS library to
reenable algorithms beyond those allowed by the system-wide policy
without the need to relax the said global policy.
== Scope ==
* Proposal owners:
GnuTLS merge request with the new functionality must be landed
downstream: https://gitlab.com/gnutls/gnutls/-/merge_requests/1427
This change will be safe to land in isolation.
Then crypto-policies will have to switch over to using the new
configuration file format/paradigm, that's where the regressions might
crop up in other components.
* Other developers:
The scope is limited to GnuTLS dependencies and transitive dependencies.
Ideally, the change should be transparent to the applications, and is
likely to go unnoticed by most GnuTLS applications. But if one flips a
ship upside down, something will fall and break, even if everything
should be, in theory, bolted down. Components that supply custom
priority strings to GnuTLS are the most risky category and should be
tested in these scenarios.
* 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 Objectives: no
== Upgrade/compatibility impact ==
No special upgrade considerations should be required.
== How To Test ==
Wait until the packages with the change are available, smoke-test
GnuTLS dependencies. No observable changes should happen.
Use cases and functionality that rely on components supplying custom
priority strings to GnuTLS are more likely to be affected than those
relying on the system defaults. For example, if a library depending on
GnuTLS enables PSK key exchanges with
gnutls_set_default_priority_append(), the functionality relying on
that should be smoke-tested.
== User Experience ==
Ideally, the change would be transparent even for developers for all
components besides gnutls and crypto-policies, let alone end-users.
OpenConnect users will finally be able to connect to endpoints stuck
with DTLS 0.9 once OpenConnect is updated to use the new API and warn
the users of the security issues of using old protocols. Other
applications using GnuTLS will be offered an opt-in choice to stray
from the system-wide defaults set by crypto-policies to interoperate
with legacy systems or import data using encryption not approved by
the system-wide policy.
== Dependencies ==
GnuTLS is a low-level package with a sizeable reverse dependency tree.
Out of "household" names, QEMU, libvirt, Samba, OpenConnect and Wget
came to mind first.
== Contingency Plan ==
* Contingency mechanism: revert to the previous denylisting
configuration file format / not switch to the new allowlisting one
* Contingency deadline: Fedora 36 Beta Freeze
* Blocks release? Unlikely, unless a major new issue with the
implementation will be uncovered.
== Documentation ==
Documentation on the new GnuTLS interface will be handled upstream.
Announcement of the fact that crypto-policies switches to the new
configuration file format in Fedora was intended to be covered by this
Fedora Change page.
== Release Notes ==
The change is not supposed to be user-visible; I only imagine it
getting to release notes in case of late-discovered bugs with the
implementation.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months
F36 Change: Enable fs-verity in RPM (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/FsVerityRPM
== Summary ==
Enable the use of fsverity for installed RPM files validation.
== Owners ==
* Name: [[User:Dcavalca|Davide Cavalca]], [[User:Borisb|Boris
Burkov]], [[User:Filbranden|Filipe Brandenburger]],
[[User:Salimma|Michel Alexandre Salim]], [[User:Malmond|Matthew
Almond]]
* Email: dcavalca(a)fb.com, borisb(a)fb.com, filbranden(a)fb.com,
michel(a)fb.com, malmond(a)fb.com
== Detailed description ==
fs-verity is a [https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
Linux kernel feature] that does transparent on-demand
integrity/authenticity verification of the contents of read-only
files, using a hidden Merkle tree (hash tree) associated with the
file. The mechanism is similar to dm-verity, but implemented at the
file level rather than at the block device level.
When fsverity is enabled for a file, the kernel reads every block and
generates a hash tree for it, which is stored within the filesystem.
On subsequent reads, the kernel computes the block hash and compares
it with the one stored in the tree, protecting against alterations and
corruption. Because this happens at the filesystem data block read
layer, it encompasses all file operations (<code>open</code>,
<code>mmap</code>,<code>exec</code>, etc.).
In the context of rpm, there are two parts to this:
* at build time, we compute the Merkle tree for the files within a
package, then sign it and ship it as part of the rpm metadata;
* at run time, if the fsverity rpm plugin is enabled, rpm will install
the fsverity signature key and enable fsverity on files that are
installed.
This proposal is primarily concerned with the first part, which will
make it possible for users to leverage fs-verity for RPM if they so
desire. Specifically, installing and enabling the fs-verity rpm plugin
by default is explicitly considered out of scope here.
=== Caveats ===
==== Merkle tree cost ====
The Merkle tree used by fsverity needs to be generated (once at build
time, once when the package is installed) and stored on disk. The
generation process involves reading all blocks and computing the hash,
which has a non-trivial cost; however, it does not appear to
meaningfully slow down package installs during empirical testing. Once
generated, the Merkle tree will use up some disk space for its storage
(about 1/127th of the original file size). Note that the Merkle tree
is ''not'' shipped with the RPM itself (only its signature is) and is
only generated and stored at install time if the fsverity rpm plugin
is enabled. Hence, there is no cost (neither in generation time nor in
disk space usage) if the plugin is disabled.
==== Signature overhead cost ====
To leverage fsverity every rpm needs to include the hash signature as
part of its metadata, which will increase its size. The signature size
is roughly proportional to the number of files in the package. From
empirical testing, in the vast majority of cases we expect to see
minimal to no size increase thanks to RPM header packing.
=== Relationship with IMA ===
[https://sourceforge.net/p/linux-ima/wiki/Home/ IMA] is another
technology meant to provide detection of file alterations. IMA and
fsverity operate very differently, and are somewhat complementary.
fs-verity works by using a Merkle tree to generate a checksum for
every data block in the system, and reads will fail if a single data
block read fails it’s checksum. The signature of the the file is
validated against a public key loaded into the kernel keyring. Because
fsverity operates on block reads, its runtime cost is small (as it
only needs to verify the block that is being accessed), and it can
protect from alterations at any point in time.
IMA works by measuring a file as a whole and comparing its signature
whenever it’s read of executed. It has a higher runtime cost than
fsverity (as it needs to verify the whole file at once) and it cannot
detect subsequent alternations. IMA provides a much more rich and
complex policy system, allowing one to define system-wide policies
around trusted files that tie into LSMs such as SELinux.
IMA and fsverity could potentially be integrated (meaning, an fsverity
backend for IMA could be implemented to leverage its policy controls),
but this is not currently planned or being worked on.
=== Relationship with native checksums ===
By default, btrfs already checksums each file extent, which could
potentially be leveraged to implement a HMAC solution. This currently
exists as a [https://lore.kernel.org/linux-btrfs/SN4PR0401MB3598DDEF9BF9BACA71A1041D9B...
patch series] but it hasn’t been merged yet. Similarly to IMA, we see
this approach as complementary to fs-verity. The
[https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in...
blog post] goes into more details of the tradeoffs involved.
== Feedback ==
Pending the devel discussion
== Benefit to Fedora ==
The main benefit is the ability to do block-level verification of
RPM-installed files. In turn, this can be used to implement
usecase-specific validation and verification policies depending on the
environment requirements.
== Scope ==
* Proposal owners
** btrfs kernel enablement work
([https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit...
landed in 5.15]); see this
[https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in...
blog post] for more details
** koji integration: koji will need to add the fs-verity metadata to
packages when signing them
* Other developers:
** deploy the koji integration changes to production
* Release engineering: tbd
* Policies and guidelines: N/A
* Trademark approval: N/A
== Upgrade/compatibility impact ==
None
== How to test ==
Install the fs-verity RPM plugin to validate package contents:
<pre>$ sudo dnf install rpm-plugin-fsverity</pre>
Note that this will only be useful if the packages being installed
contain the appropriate fs-verity metadata (which, for Fedora upstream
packages, requires Koji integration that is part of this Change).
However, you should still be able to test this if you locally sign a
package with <code>rpmsign --addverity</code>.
== User experience ==
This Change is fully transparent and there is no user impact by
default. If the user chooses to enable the fs-verity RPM plugin, they
can then leverage the additional verification features provided by
fs-verity.
== Dependencies ==
* fs-verity support is available in RPM as of 4.17, which is available
as of Fedora 35 and is already enabled in rpm-4.17.0-0.rc1.0.fc36
* CONFIG_FS_VERITY in the kernel config; this is already enabled
* fs-verity requires filesystem support; currently support for ext4
and f2fs is already available; support for btrfs landed in 5.15
* there is no filesystem dependency on the builders, only at runtime
(and only if the rpm fsverity plugin is installed and one wishes to
use it)
== Contingency plan ==
Revert the changes to koji.
== Documentation ==
* https://www.kernel.org/doc/html/latest/filesystems/fsverity.html
* https://developers.facebook.com/blog/post/2021/10/19/fs-verity-support-in...
* The proposal owners plan to document the fsverity plugin and
integration in RPM
(https://github.com/rpm-software-management/rpm/issues/1849)
== Release Notes ==
The RPM package manager now supports validation of file contents using
fs-verity.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 4 months