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-2022-04-12.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
===============================================================================
beanstalk-client orphan 5 weeks ago
gnome-shell-extension-material-shell atim, orphan 0 weeks ago
golang-github-astaxie-beego go-sig, orphan 0 weeks ago
golang-github-influxdata-influxdb go-sig, orphan 2 weeks ago
golang-github-mdlayher-wifi go-sig, orphan 4 weeks ago
hd-idle atim, orphan 1 weeks ago
lua-ldap orphan 5 weeks ago
mcrcon orphan 1 weeks ago
python-aiohttp-cors orphan, python-sig 5 weeks ago
python-aiohttp-negotiate orphan 5 weeks ago
python-fastimport orphan 5 weeks ago
python-lrparsing orphan 5 weeks ago
python-ofxparse orphan 5 weeks ago
python-plyvel orphan 5 weeks ago
python-pystalk orphan 5 weeks ago
qcommandline orphan 5 weeks ago
qt5-qtcanvas3d kde-sig, orphan 3 weeks ago
qt5-qtenginio kde-sig, lupinix, orphan 3 weeks ago
rubygem-request_store orphan 1 weeks ago
rust-diffus orphan, rust-sig 3 weeks ago
rust-diffus-derive orphan, rust-sig 3 weeks ago
rust-newsblur_api orphan, rust-sig 3 weeks ago
rust-opml orphan, rust-sig 3 weeks ago
rust-xmltree orphan, rust-sig 3 weeks ago
yecht orphan 4 weeks ago
The following packages require above mentioned packages:
Depending on: golang-github-mdlayher-wifi (1), status change: 2022-03-11 (4
weeks ago)
golang-github-prometheus-node-exporter (maintained by: eclipseo, go-sig)
golang-github-prometheus-node-exporter-1.3.1-6.fc36.src requires
golang(github.com/mdlayher/wifi) = 0-0.12.20200729git84f0b94.fc36
golang-github-prometheus-node-exporter-devel-1.3.1-6.fc36.noarch requires
golang(github.com/mdlayher/wifi) = 0-0.12.20200729git84f0b94.fc36
Depending on: python-aiohttp-cors (1), status change: 2022-03-02 (5 weeks ago)
gns3-server (maintained by: kwizart, nucleo)
gns3-server-2.2.31-2.fc37.noarch requires python3.10dist(aiohttp-cors) = 0.7
Depending on: rust-diffus (1), status change: 2022-03-20 (3 weeks ago)
newsflash (maintained by: ignatenkobrain, rust-sig)
newsflash-1.5.1-2.fc36.src requires crate(diffus/default) = 0.10.0,
crate(diffus/derive) = 0.10.0
Depending on: rust-diffus-derive (2), status change: 2022-03-20 (3 weeks ago)
rust-diffus (maintained by: orphan, rust-sig)
rust-diffus+derive-devel-0.10.0-2.fc36.noarch requires
crate(diffus-derive/default) = 0.10.0
rust-diffus+diffus-derive-devel-0.10.0-2.fc36.noarch requires
crate(diffus-derive/default) = 0.10.0
rust-diffus+serialize-impl-devel-0.10.0-2.fc36.noarch requires
crate(diffus-derive/serialize-impl) = 0.10.0
newsflash (maintained by: ignatenkobrain, rust-sig)
newsflash-1.5.1-2.fc36.src requires crate(diffus/default) = 0.10.0,
crate(diffus/derive) = 0.10.0
Depending on: rust-newsblur_api (2), status change: 2022-03-15 (3 weeks ago)
rust-news-flash (maintained by: ignatenkobrain, rust-sig)
rust-news-flash-1.2.1-6.fc36.src requires crate(newsblur_api/default) = 0.1.2
rust-news-flash-devel-1.2.1-6.fc36.noarch requires
crate(newsblur_api/default) = 0.1.2
newsflash (maintained by: ignatenkobrain, rust-sig)
newsflash-1.5.1-2.fc36.src requires crate(news-flash/default) = 1.2.1
Depending on: rust-opml (2), status change: 2022-03-20 (3 weeks ago)
rust-news-flash (maintained by: ignatenkobrain, rust-sig)
rust-news-flash-1.2.1-6.fc36.src requires crate(opml/default) = 1.1.1
rust-news-flash-devel-1.2.1-6.fc36.noarch requires crate(opml/default) = 1.1.1
newsflash (maintained by: ignatenkobrain, rust-sig)
newsflash-1.5.1-2.fc36.src requires crate(news-flash/default) = 1.2.1
Depending on: rust-xmltree (1), status change: 2022-03-20 (3 weeks ago)
newsflash (maintained by: ignatenkobrain, rust-sig)
newsflash-1.5.1-2.fc36.src requires crate(xmltree/default) = 0.10.3
Affected (co)maintainers (either directly or via packages' dependencies):
atim: gnome-shell-extension-material-shell, hd-idle
eclipseo: golang-github-mdlayher-wifi
go-sig: golang-github-mdlayher-wifi, golang-github-influxdata-influxdb,
golang-github-astaxie-beego
ignatenkobrain: rust-diffus, rust-xmltree, rust-newsblur_api, rust-opml,
rust-diffus-derive
kde-sig: qt5-qtcanvas3d, qt5-qtenginio
kwizart: python-aiohttp-cors
lupinix: qt5-qtenginio
nucleo: python-aiohttp-cors
python-sig: python-aiohttp-cors
rust-sig: rust-diffus, rust-xmltree, rust-newsblur_api, rust-opml,
rust-diffus-derive
--
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
Report finished at 2022-04-12 07:15:34 UTC
2 years
F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval
== Summary ==
This change will remove the `xorg-x11-drv-vesa` and
`xorg-x11-drv-fbdev` driver packages, and associated support code from
the `xorg-x11-server-Xorg` package.
== Owner ==
* Name: [[User:ajax|Adam Jackson]]
* Email: ajax(a)redhat.com
== Detailed Description ==
Fedora's primary desktop environments are moving away from being X11
sessions, to being Wayland servers in their own right. This transition
is incomplete, and the Xorg server is still potentially used in a
variety of "fallback" situations. In particular the `vesa` and `fbdev`
drivers can find themselves pressed into use when accelerated graphics
is unavailable. Both of these drivers are somewhat deprecated
upstream, and the code to reach them is increasingly fragile as it
gets exercised less and less.
This change will identify the remaining configurations that can reach
these drivers, establish an alternative for display support for each
configuration, and then remove the drivers and their support code in
xserver.
== Feedback ==
None yet.
== Benefit to Fedora ==
* Verified modern supported paths for cases currently handled by vesa/fbdev
* Simpler support/testing matrix for QE
* One less reason to need Xorg installed at all
== Scope ==
* Proposal owners: ajax needs to audit hardware support matrix for
cases that can hit these drivers, and the rest of the OS for places
that can configure them.
* Other developers: Maintainers of other affected components may need
to incorporate some changes, and may wish to look for additional
support code that can be dropped.
* Release engineering: This is mostly ensuring that the two driver
packages are indeed dropped from the compose, etc.
* Policies and guidelines: N/A (not needed for this Change) Although
this is a system-wide change I don't think there's any real policy
impact.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: Yes, we'd be arguably the First to try this.
== Upgrade/compatibility impact ==
For an upgraded system to notice this change, it would need to be
already using one of these drivers. For cases we can identify where
this would happen without explicit configuration, we will ensure the
display is enabled by some other path or documented as no longer
supported. However, for cases where the driver is set explicitly in
`xorg.conf`, there is no obviously correct remedy that we could do
automatically, and the user will need to fix their X configuration
manually.
== How To Test ==
This should fall out naturally from the normal release testing
process, but we'll expand the details here as the various
configurations are tested and fixed.
== User Experience ==
This change should be largely invisible, but there will likely be
observable changes (for instance, if you end up using a Wayland
session, `$WAYLAND_DISPLAY` will likely no longer be empty). These
will be documented here as we fix the individual cases.
== Dependencies ==
The kernel may need changes to add more drivers for more situations.
The installer and other system-wide configuration tools should be
audited to ensure they don't emit cases that can force vesa/fbdev.
The major desktop environments may need to be fixed to handle more
cases, and may wish to drop code to support the old cases.
== Contingency Plan ==
* Contingency mechanism: ajax reverts the changes.
* Contingency deadline: Beta freeze seems fine.
* Blocks release? No. Partial completion is possible.
== Documentation ==
Just this page so far.
== Release Notes ==
None yet.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years
F37 Change: RPM 4.18 (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/RPM-4.18
== Summary ==
Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release.
== Owner ==
* Name: [[User:pmatilai|Panu Matilainen]]
* Email: pmatilai(a)redhat.com
== Detailed Description ==
RPM 4.18 contains various improvements over previous versions, but in
particular this release addresses a whole class of symlink handling
related security issues, some with CVE's, from 2021. Other notable
improvements include
* A more intuitive conditional builds macro `%bcond`
* A more robust and secure `--restore` functionality
* Long-standing `%patch` quirks fixed
* Weak dependencies accept qualifiers like `meta` and `pre` now
* New interactive shell for working with macros (`rpmspec --shell`)
and embedded Lua (`rpmlua`)
* New `%conf` spec section for build configuration
* New `rpmuncompress` cli tool simplifies unpacking multiple sources
* Numerous macro improvements and fixes
* Numerous OpenPGP parser correctness and security fixes
== Benefit to Fedora ==
The main benefits of this release are increased security and packaging
experience improvements, see above for details.
== Scope ==
* Proposal owners:
** Rebase RPM
** Assist with dealing with incompatibilities
* Other developers:
** Test new release, report issues and bugs
* Release engineering: [https://pagure.io/releng/issue/10742 #10742]
* Policies and guidelines: N/A (not needed for this Change). Utilizing
new rpm features is subject to packaging guidelines but othe
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives: N/A (no relation to current objectives)
== Upgrade/compatibility impact ==
There are no noteworthy compatibility issues with this release.
== How To Test ==
Rpm receives a thorough and constant testing via every single package
build, system installs and updates. New features can be tested
specifically as per their documentation.
== User Experience ==
There are no major differences in the normal user experience.
== Dependencies ==
* No new dependencies are introduced in this release
* Other changes are known to be affected
* Library soname will not change so no rebuilds are required
== Contingency Plan ==
* Contingency mechanism: Revert back to RPM 4.17
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
Work-in-progress release notes at https://rpm.org/wiki/Releases/4.18.0
and reference manual at
https://github.com/rpm-software-management/rpm/blob/master/doc/manual/ind...
== Release Notes ==
https://rpm.org/wiki/Releases/4.18.0
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years
Bodhi 6.0: What's new
by Aurelien Bompard
Hey everyone!
Bodhi 6.0 will be published in a few days, and deployed to production a
couple weeks after the Fedora release. It has backwards-incompatible
changes, here's what you need to know.
== Authentication ==
Bodhi gained support for OpenID Connect (OIDC) authentication, like most of
Fedora's webapps. OpenID still works but is not the default, you can access
it by using `/login?method=openid` as the login URL.
Version 6.0 of the Bodhi client uses only OIDC, plain OpenID support has
been dropped. Version 5.7.5 of the Bodhi client, however, uses the new
OpenID login URL and has been available for about a month now, you'll need
at least version 5.7.5 to use the Bodhi client with the updated server.
The client's API has changed, so if you have a piece of code that imports
from `bodhi.client`, you'll have to update it to use the new API, and in
the meantime use version 5.7.5.
As a user of the `bodhi` CLI, you'll notice that the `--username` and
`--password` options have disappeared. Instead the Bodhi client will ask
you to open your browser to a URL to authenticate. The authentication
tokens will be saved and you'll be able to use the `bodhi` CLI without
authenticating afterwards (or non-interactively).
== Code reorganization ==
The Bodhi source code has been reorganized to drop the hacks used in
`setup.py` to support sub-projects. Instead, `bodhi-server`, `bodhi-client`
and `bodhi-messages` are now actual Python package directories in the repo.
The import path has not changed.
Bodhi's Python project metadata and dependencies are now managed with
Poetry <https://python-poetry.org/>.
== Other changes ==
- Serialized `Release` objects sent in the messages don't contain the
`composes` property anymore
- The `koji-build-group.build.complete` messages now contain an `update`
property
- In the Bodhi client API, the `save_override()` method has been extended
to allow setting the expiration date directly
- Misc bug fixes
If you have any questions, feel free to ask the Bodhi team in our matrix
room: <https://matrix.to/#/#bodhi:matrix.org>.
If you are importing the bodhi client code in your app/script, or using the
bodhi client in an "unusual" manner, we'll help you migrate.
Thanks!
Aurélien Bompard
2 years, 1 month
F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS
== Summary ==
Make UEFI a hardware requirement for new Fedora installations on
platforms that support it (x86_64). Legacy BIOS support is not
removed, but new non-UEFI installation is not supported on those
platforms. This is a first step toward eventually removing legacy
BIOS support entirely.
== Owner ==
* Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří
Konečný]], [[User:bcl| Brian C. Lane]]
* Email: rharwood(a)redhat.com
== Detailed Description ==
UEFI is defined by a versioned standard that can be tested and
certified against. By contrast, every legacy BIOS is unique. Legacy
BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple)
and on its way out. As it ages, maintainability has decreased, and
the status quo of maintaining both stacks in perpetuity is not viable
for those currently doing that work.
It is inevitable that legacy BIOS will be removed in a future release.
To ease this transition as best we can, there will be a period (of at
least one Fedora release) where it will be possible to boot using the
legacy BIOS codepaths, but new installations will not be possible.
While it would be easier for us to cut support off today, our hope is
that this compromise position will make for a smoother transition.
Additional support with issues during the transition would be
appreciated.
While this will eventually reduce workload for boot/installation
components (grub2 reduces surface area, syslinux goes away entirely,
anaconda reduces surface area), the reduction in support burden
extends much further into the stack - for instance, VESA support can
be removed from the distro.
Fedora already requires a 2GHz dual core CPU at minimum (and therefore
mandates that machines must have been made after 2006). Like the
already accepted Fedora 37 change to retire ARMv7 support, the
hardware targeted tends to be rather underpowered by today’s
standards, and the world has moved on from it. Intel stopped shipping
the last vestiges of BIOS support in 2020 (as have other vendors, and
Apple and Microsoft), so this is clearly the way things are heading -
and therefore aligns with Fedora’s “First” objective.
== Feedback ==
Dropping legacy BIOS was previously discussed (but not proposed) in 2020:
https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject...
Important, relevant points from that thread (yes, I reread the entire
thread) that have informed this change:
* Some machines are BIOS-only. This change does not prevent their use
yet, but they are effectively deprecated. grub2 (our default
bootloader) is already capable of both BIOS and UEFI booting.
* Drawing a clear year cutoff, let alone a detailed list of hardware
this change affects, is basically impossible. This is unfortunate but
unlikely to ever change.
* There is no migration story from Legacy BIOS to UEFI -
repartitioning effectively mandates a reinstall. As a result, we
don’t drop support for existing Legacy BIOS systems yet, just new
installations.
* There is no way to deprecate hardware without causing some amount of friction.
* While at the time AWS did not support UEFI booting, that is no
longer the case and they support UEFI today.
== Benefit to Fedora ==
UEFI is required for many desirable features, including applying
firmware updates (fwupd) and supporting SecureBoot. As a standalone
change, it reduces support burden on everything involved in installing
Fedora, since there becomes only one way to do it per platform.
Finally, it simplifies our install/live media, since it too only has
to boot one way per arch. Freedom Friends Features First - this is
that last one.
== Scope ==
* Proposal owners:
** bootloaders: No change (existing Legacy BIOS installations still supported).
** anaconda: No change (there could be only optional cleanups in the
code). However, it needs to be verified.
** Lorax: Code has already been written:
https://github.com/weldr/lorax/pull/1205
* Other developers:
** libvirt: UEFI works today, but is not the default. UEFI-only
installation is needed for Windows 11, and per conversations, libvirt
is prepared for this change.
** Virtualbox: UEFI Fedora installs are working and per virtualbox
team, UEFI will be/is the default in 7.0+.
** The Hardware Overview page should be updated to mention the UEFI
requirement: https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome...
* Release engineering: [https://pagure.io/releng/issue/10738 #Releng
issue 10738]
* 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 ==
Systems currently using Legacy BIOS for booting on x86_64 will
continue to do so.
However, this modifies the baseline Fedora requirements and some
hardware will no longer be supported for new installations.
== How To Test ==
UEFI installation has been supported for quite a while already, so
additional testing there should not be required.
== User Experience ==
Installs will continue to work on UEFI, and will not work on Legacy
BIOS. Our install media is already UEFI-capable.
== Dependencies ==
None
== Contingency Plan ==
Leave things as they are. Code continues to rot. Community
assistance is required to continue the status quo. Current owners
plan to orphan some packages regardless of whether the proposal is
accepted.
Another fallback option could be, if a Legacy BIOS SIG organizes, to
donate the relevant packages there and provide some initial mentoring.
Longer term, packages that cannot be wholly donated could be split,
though it is unclear whether the synchronization thereby required
would reduce the work for anyone.
* Contingency mechanism: Delay until next release.
* Contingency deadline: Beta freeze
* Blocks release? No
== Documentation ==
See release notes.
== Release Notes ==
Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in
favor of UEFI. While systems already using Legacy BIOS to boot are
still supported, new legacy BIOS installations on these architectures
are no longer possible. Legacy BIOS support will be removed entirely
in a future Fedora.
(Additionally, the Hardware Overview page should be updated to mention
the UEFI requirement.)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 1 month
F37 Change: Signed RPM Contents (System-Wide Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents
== Summary ==
We want to add signatures to individual files that are part of shipped RPMs.
These signatures will use the Linux IMA (Integrity Measurement
Architecture) scheme, which means they can be used to enforce runtime
policies to ensure execution of only trusted files.
== Owner ==
* Name: [[User:Pbrobinson| Peter Robinson]]
* Email: pbrobinson(a)gmail.com
* Name: [[User:Puiterwijk| Patrick Uiterwijk]]
* Email: puiterwijk(a)redhat.com
== Detailed Description ==
During signing builds, the files in it will be signed with IMA signatures.
These signatures will be made with a key that's kept by the Fedora
Infrastructure team, and installed on the sign vaults.
These signature can then be used with the Linux Integrity Measurement
Architecture (IMA) kernel subsystem to verify files on execution based
on a policy.
The IMA subsystem is described on
[https://sourceforge.net/p/linux-ima/wiki/Home/ the project page].
IMA allows users to extend the trust of their system to the OS and
processes. It allows the users, if they so wish, to set polices to
ensure their machine and their resources are used the way they
intended it to be not about restricting the use for the average Fedora
user.
Like all security pieces IMA doesn't solve the whole security problem
with a single option, it's not intended to, but that does not mean it
doesn't provide additional value and tools for Fedora users to protect
their systems. To quote a section of [https://lwn.net/Articles/753276/
an LWN article]:
<pre>
The goals of the integrity subsystem are to detect files that have
been altered, either accidentally or maliciously, by comparing a
measurement of the current file contents with that of a stored "good"
value; it can then enforce various file integrity policies (e.g. no
access or no execution). IMA is three separate pieces: measurement,
which calculates a hash of file contents; appraisal, which verifies
file signatures made using the measured hashes; and audit, which
records hashes and other information in the audit logs. There is also
the extended verification module (EVM), which targets the measurement
and protection of the file metadata, though that is not included in
what she would be presenting.
It is important to note that IMA does not protect against attacks on
objects in memory, it can only be used to thwart attacks that change
files.
</pre>
The intention here is not to ship a default policies for users but
rather have sample policies that users can modify and use themselves.
The Fedora IoT Edition intends to have sample policies and
documentation for a number of IoT and Edge use cases.
This means that they can configure a policy based on which the kernel
will determine whether to verify (or measure) files before opening
them.
You could for example make a policy that appraises (verifies) all
files that are executed by root: `appraise uid=1000
appraise_type=imasig`.
Note explicitly that we do not intend to install a default policy as
part of this change, and users will need to deploy their own policy
before anything is measured or appraised.
This means that after this is done, users will have the option to
enable a policy and have that be enforced, but there will be nothing
automatic.
We will, however, document various example policies people can adapt
to their needs.
By default, the signatures will not be deployed to the file system.
That will only be done once rpm-plugin-ima is installed.
After that, RPM will put the signatures on the "security.ima" extended
attribute on the files.
== Feedback ==
<!-- Summarize the feedback from the community and address why you
chose not to accept proposed alternatives. This section is optional
for all change proposals but is strongly suggested. Incorporating
feedback here as it is raised gives FESCo a clearer view of your
proposal and leaves a good record for the future. If you get no
feedback, that is useful to note in this section as well. For
innovative or possibly controversial ideas, consider collecting
feedback before you file the change proposal. -->
=== RPM Size ===
One of the main concerns that have been voiced is the RPM size, both
on disk (mirrors) and on an installed system.
For this comparison, I have cached all the RPMs installed in a Fedora
Rawhide 20210118.n.1 default Server install (server netinstall disk,
and then no changes to the group selection).
After creating two copies of that data, one with just resigned (to
exclude rpm size difference resulting from different key lengths), and
one resigned with IMA file signatures inserted, I then installed two
blank VMs by using the standard virt-manager settings, changing only
the name and the system type to "EFI".
This is using a prime256v1 file signing key. This is the same key
format supported by the Fedora signing system.
==== Binary RPMs on disk ====
Resigned: 462524 (452M)
Resigned+IMA: 467812 (457M)
This comes down to a 1.1% increase on size of the binary RPMs.
==== Installed size ====
On installation of two different VMs, one with the resigned RPMs, and
one with the resigned+ima RPMs, the `/usr` directory size does not
change at all (both are exactly 1417064 bytes).
The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase.
This is on an install size of 1.7GB in total, so this 5MB increase is
a 0.3% size increase on the final installed system.
Note that both of those VMs did not have rpm-plugins-ima installed,
which means the file signatures are not put in place.
When I install the rpm-plugin-ima, and run "dnf reinstall *", the
`/usr` directory increases by 0.002% to 1417104.
==== RPM header size bug ====
There was a bug in rpm from when file signatures were moved over from
the header into the sigheader. Details
[https://pagure.io/fesco/issue/2547#comment-711253 here]. This bug is
fixed in Fedora and RHEL-8.
=== Tie-in to Secure Boot ===
While using the IMA subsystem in combination with Secure Boot enables
users to extend trust on the system out into the binaries executed,
there is no requirement at all to use secure boot.
This means that if you have Secure Boot enabled, that enables you to
extend the trust, but if you don't want to use secure boot, that has
no impact on the IMA subsystem.
=== Why in the RPM header, instead of a side-package like -debuginfo? ===
These signatures would need to get deployed as a filesystem extended
attribute in order to be used by the IMA subsystem.
While it is possible to generate the signatures as separate files in a
side package, that means that RPM would then need to add code to
install extended attributes based on contents of another RPM package.
This would mean that the contents of an e.g. `-file-signature`
subpackage won't be deployed to the file systems as normal files, but
instead as xattr's on existing files.
That, together with the minimal size increases of the actual RPMs,
made us decide to go with the signature header approach and not
implement the side-package method.
=== Comparison with MAC's ===
The IMA subsystem is orthogonal to the Mandatory Access Control
systems like selinux, though it is integrated with them.
Where with selinux you can limit who can read from or write to to
which file, IMA will allow you to set policies that enforce file
contents to be as expected (signature validated) before they can be
read/executed.
The integration is in the form that you can write a policy line that
matches on certain selinux contexts, like for example `dont_appraise
obj_type=var_log_t`, to ensure that files of `var_log_t` do not need
to be verified, and `appraise obj_type=shell_exec_t` to ensure that
any shell that is executed (e.g. bash) is signed with a trusted key.
=== Why not ... ===
==== fsverity ====
As one of the fsverity maintainers has said on
[https://lwn.net/Articles/842326/|LWN]: IMA and FS-Verity are not
mutually exclusive, but at this moment IMA has a possibility to
enforce a system-wide policy instead of needing the userspace binaries
to check the signature status themselves.
There's currently competing proposals for upstream kernel for
functionality like integration with IMA
[https://www.spinics.net/lists/linux-integrity/msg21056.html this one]
and [https://www.spinics.net/lists/linux-integrity/msg20947.html this
one]. The proposal also requires
[https://www.spinics.net/lists/linux-integrity/msg20713.html Adding
PGP support to the kernel] which isn't upstream and may take some
time.
The [https://fedoraproject.org/wiki/Changes/FsVerityRPM FsVerity]
feature also needs enhancements across Fedora including changes to
koji, additions to rpm and well as filesystems that support it. It's
also got limited filesystem support, for example it's not supported on
XFS which is the default on the Server Edition.
==== DIGLIM ====
The Digest Lists Integrity Module (DIGLIM) isn't actually independent
of this feature, it still requires digests of the files such as the
ones generated here in this proposal, it just consumes them in a
different method than IMA on the end system. Rather than embedding
them in xattr on the filesystem as IMA does the kernel loads them into
memory.
Ultimately DIGLIM is complementary and has the ability to build on top
of this functionality once this actually makes it upstream.
==== rpm -V ====
rpm -V will tell you whether a file matches the digest that's in the
RPM Database, but that is useful if you think a file might have been
accidentally changed. If an attacker has the opportunity to change a
file on the file system, it is very likely they could also update the
RPM binary (or the rpmdb) to make it not report the change.
IMA signatures will be able to identify the file to have been changed,
and importantly also enable a policy which enforces the signatures,
which means that if a change was made to a file that is matched by a
policy, the kernel would actively refuse loading it, instead of
depending on the administrator to check its validity with a known-good
rpm database and binary.
== Benefit to Fedora ==
Having all files signed with a verifiable key means that system owners
can use the kernel Integrity and Measurement Architecture (IMA) to
enforce only verified files can be executed, or define other policies.
Having all files signed with Fedora keys would enable integration with
for example [https://keylime.dev/ Keylime], which is a CNCF project
that implements remote system attestation, based on which a system may
or may not get access to secrets and other consequences.
This feature is wanted by the IoT Edition, for enabling both
attestation and local policy verification.
Many IoT users have expressed interest in this functionality and are
already working to build on it.
IMA doesn't solve all security issues but it provides an extra useful
tool to those that wish provide higher levels of security on their
devices. From other proposals such as the fsverity and DGLIM ones
there is clearly a desire to be able to provide this style of extra
security to Fedora users.
An advantage that this proposal has, that the others do not currently
provide, is that all the functionality is in place in koji, the
signing infrastructure, the various packages and kernel now and
doesn't depend on out of tree patches to get into various upstream
projects or work on Fedora infrastructure to be scheduled.
== Scope ==
* Proposal owners:
The proposal owners will generate the keys in Infrastructure and get
them deployed to the sign vaults, and enable the configuration options
for this in robosignatory.
Support for file signatures is already in the deployed versions of
sigul and robosignatory.
* Other developers:
Nothing needed from other developers
* Release engineering: [https://pagure.io/releng/issue/10731 #10731]
A mass rebuild would be nice (as it ensures all packages are signed),
but is not required to implement the change itself.
* Policies and guidelines:
No impact
* Trademark approval:
No impact
* Alignment with Objectives:
This aligns with the Internet of Things objective.
== Upgrade/compatibility impact ==
For standard Fedora users there will be a very tiny increase in rpmdb
size. If an advanced user was already signing their own files (for the
Fedora shipped RPMs) for IMA functionality, they will just overwrite
the existing signature.
== How To Test ==
You can verify that a signature has been put in place by looking at
the extended attribute by running: `getfattr -d -m security.ima
/usr/bin/bash` (change `/usr/bin/bash` with the file to check).
The signatures can be tested “in vitro” by running `evmctl ima_verify
--key publiccert.der -v myfile.txt`.
This should result in the system reporting “<filename>: verification is OK”.
The full system could be tested by enrolling the Fedora IMA key to the
kernel `_ima` keyring, and adding a policy that verifies (some) files
to be verified against the key. (instructions to follow).
== User Experience ==
If the user deploys an IMA policy to verify all or some files, they
should be able to trust the signatures made by the Fedora build
system.
== Dependencies ==
No external package dependencies.
== Contingency Plan ==
* Contingency mechanism: None. The development work is already
complete and all the infrastructure functionality is upstream.
* Contingency deadline: The signing should be turned on before a mass
rebuild, and is ready to go if the change is approved.
* Blocks release? No
* Blocks product? N/A
== Documentation ==
We intend to write documentation on how to use the IMA subsystem for
docs.fedoraproject.org, but that is orthogonal to this feature itself.
We expect to provide example policies users can use to base their policy on.
== Release Notes ==
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years, 1 month