devel-announce

devel-announce@lists.fedoraproject.org

1 participants
3690 discussions

F41 Change Proposal: Enabling composefs by default for Atomic Desktops, CoreOS and IoT (Self-Contained)
by Aoife Moloney 24 Jun '24

24 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/ComposefsAtomicCoreOSIoT Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-enabling-compose… 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 enable composefs by default for Fedora Atomic Desktops, Fedora CoreOS and Fedora IoT. This makes the root mount of the system (`/`) a truly read only filesystem, increasing the system integrity and robustness. This is the first step toward a full ''at runtime'' verification of filesystem integrity. This change will be enabled only for the Bootable Container images of Fedora Atomic Desktops and not the classic ostree ones. == Owner == * [[User:jbtrystram| Jean-Baptiste Trystram]], jbtrystram(a)redhat.com * [[User:Siosm| Timothée Ravier]], siosm(a)fedoraproject.org * [[User: pwhalen| Paul Whalen]], pwhalen(a)fedoraproject.org == Detailed Description == Ostree based systems currently have `/usr` mounted as read-only and managed by ostree/rpm-ostree. The integrity of the content of `/usr` is only validated by ostree/rpm-ostree during updates and deployment operations, but not at "runtime". If a file is corrupted on disk (maliciously or not), it will only be detected if a full check is performed using `ostree fsck`. On those systems, the runtime root (`/`) of the system is currently mounted as read-write but with the `immutable` bit set (`chattr +i /`) to prevent accidental modifications. [https://github.com/containers/composefs composefs] is a new project that combines several existing filesystems (overlayfs, EROFS) to provide a very flexible mechanism to support read-only mountable filesystem trees, stacking on top of an underlying "lower" Linux filesystem. Using composefs, it will no longer be possible to mutate the underlaying file content that is part of the system (`/usr`) nor the layout of the root directory. It will result in I/O errors at the kernel level. The content is `/etc` and `/var` will remain writtable as it is today. This change is part of the [https://fedoraproject.org/wiki/Initiatives/Fedora_bootc Fedora Bootable Containers Initiative]. The `bootc` container images already enable composefs thus this change is to align existing variants to the new Bootable Containers defaults. It is tracked in: * Fedora Atomic Desktops: https://gitlab.com/fedora/ostree/sig/-/issues/35 * Fedora CoreOS: https://github.com/coreos/fedora-coreos-tracker/issues/1718 * Fedora IoT: https://github.com/fedora-iot/iot-distro/issues/52 This is the first step toward a full boot chain integrity, that will requiring signing the composefs metadata during composes and using Unified Kernel Images (UKI). See: https://gitlab.com/fedora/bootc/tracker/-/issues/14 As podman also use composefs to store containers layers, this enable deduplication of files between containers and host. This will result in less disk usage but also faster container startup and less memory use. See https://github.com/containers/composefs/issues/125 == Feedback == Nothing specific so far. We have the following "known issues": * Conflicts with `ostree-grub2`, which impacts Dual Boot support: ** https://github.com/ostreedev/ostree/issues/3198 ** We will remove ostree-grub2 from Fedora Atomic Desktops bootable container images ** Related to: https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd ** We can do this ''now'' for the container images as they are not officially released for Fedora, and generally ''newer'', so it's more likely that the bootloader on those systems are already BLS capable. ** We can not do this for "classic ostree" Atomic Desktops yet as we need a transition period with bootupd enabled by default before removing ostree-grub2. ** However with the recent Secure Boot issue (https://github.com/fedora-silverblue/issue-tracker/issues/543) forcing everybody to manually update their bootloader, we might be able to shorten this transition period. ** See for Dual Boot: https://github.com/fedora-silverblue/issue-tracker/issues/530 * No longer possible to create root level direcotries (`chattr -i` workaround): ** Requires derivation, thus the container flow ** https://github.com/coreos/rpm-ostree/issues/337 ** Alternative: https://github.com/ostreedev/ostree/pull/3114 ** Might impact Podman Desktop for Fedora CoreOS. They will likely disable it until a solution is found. * Issues with kdump: ** https://bugzilla.redhat.com/show_bug.cgi?id=2284097 ** https://gitlab.com/fedora/bootc/tracker/-/issues/19 == Benefit to Fedora == This will increase the robustness of image based Fedora systems and prepare them for future increased security guarantees. This will align the existing image based variants of Fedora (Atomic Desktops, CoreOS, IoT) to the work that is done as part of the Bootable Containers Initiative. == Scope == * Proposal owners: ** Enable composefs in Atomic Desktops (bootable containers only) ** Enable composefs in CoreOS ** Enable composefs in IoT * Other developers: ** Applications doing disk-full checks on `/` will have to be updated to look at other places as `/` will be small (a few MB) and full (100% used). * 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 2028: ** Aligns with the goal: "Immutable variants are the majority of Fedora Linux in use" == Upgrade/compatibility impact == To be fleshed out == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == * Make sure that you do not rely on Dual Boot support * Make sure that you bootloader is recent enough to support BLS configs ** If you don't know, update it using the instructions from https://github.com/fedora-silverblue/issue-tracker/issues/543#issuecomment-… first * Remove `ostree-grub2` from the upcoming deployment: `rpm-ostree override remove ostree-grub2` * Enable composefs: `sudo ostree config set ex-integrity.composefs yes` * Update your system to a new version: `rpm-ostree update` ** Or do a manual (re)deploy of the current version: `sudo ostree admin deploy fedora/39/x86_64/silverblue` * Reboot into the new deployment == User Experience == The main visible change will be that the root filesystem (`/`) is now small and full (a few MB, 100% used). The real root is mounted in `/sysroot` and most of the data is stored in `/var`. == Dependencies == For the Atomic Desktops, this change depends on: * Bootupd support: ** https://gitlab.com/fedora/ostree/sig/-/issues/1 ** https://fedoraproject.org/wiki/Changes/FedoraSilverblueBootupd CoreOS and IoT already do not depends on `ostree-grub2`. == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) Undo the change. It's a single line change in a configuration file. * Contingency deadline: Beta Freeze / Release Freeze * Blocks release? No == Documentation == To be written. == Release Notes == To be written once the change is accepted. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F41 Change Proposal: acpica-tools: Deprecate Big Endian Support (System-Wide)
by Aoife Moloney 24 Jun '24

24 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/Acpica-tools_Deprecate-Big_Endian_Su… Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-acpica-tools-dep… 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 == The acpica-tools package has supported big-endian architectures for several years, but it has few uses. For Fedora 41, remove all of the patches for big-endian support and remove s390x from the list of supported architectures. == Owner == * Name: [[User:ahs3| Al Stone]] * Email: ahs3(a)fedoraproject.org == Detailed Description == For many years, the acpica-tools package has supported the big-endian s390x architecture, despite ACPI being a little-endian ''only'' standard. This made sense originally, as some s390x packages had to have mechanisms for dealing with ACPI tables, and there were several packages with build dependencies since they created ACPI tables. Neither of these is really true any longer. What's more, big-endian support has always had a fairly high cost. In the first place, upstream wants nothing to do with big-endian support; it is completely irrelevant, despite several attempts to get them to accept it. Secondly, every release of the upstream source requires significant backporting of the big-endian patches, creating new patches to support new features of, or changes in, the ACPI standard, and then testing and debugging the results. In the last ten years, the least amount of time to do this was two full days; the longest it has taken has been two full weeks. One has to plan for at least a week. And finally, the need for big-endian has diminished considerably. At one point, some virtualization functions required these tools so that there was no virtualization on s390x without them; again, this is no longer true. The actual changes to the acpica-tools package will actually simplify maintenance significantly. The change itself is fairly straightforward: remove the big-endian patches, and add s390x to ExcludeArch. == Feedback == This proposal was actually prompted by a recent PR on acpica-tools requesting a way to ignore the big-endian patches: [https://src.fedoraproject.org/rpms/acpica-tools/pull-request/5]. Upstream has ''never'' accepted big-endian support. Should this proposal be accepted, it would be one way of meeting the request behind the PR, however. Some discussion has occurred with s390x supporters (both recently, and in the past) that would indicate this would be something that is not ideal (no one likes to lose packages), but doesn't really create problems. Part of the reason for making this proposal is to be sure I'm not missing something. == Benefit to Fedora == The primary benefit to this proposal is that it simplifies maintenance significantly. Of the 69 patches for the package, 49 can simply be removed. The longest and most difficult builds will not be needed; the s390x testing that always takes most of the package update time will no longer be needed either. This will make it easier to ensure that acpica-tools more closely matches upstream than has been possible recently, producing a higher quality package quicker. == Scope == * Proposal owners: The actual changes to the acpica-tools package will be to remove the big-endian patches, and add s390x to ExcludeArch. This is quite straightforward. * Other developers: Based on an initial investigation, it appears that most changes will be to simply exclude s390x. So far, the only packages that seem to be affected are hw-probe, vim-syntastic-asl, and edk2. There appears to be some use outside of Fedora (xorg-x11-drv-nvidia, their proprietary drivers, for some reason). * Release engineering: This change only affects the specific packages mentioned so far. * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == Only s390x systems would notice a change in that this package would no longer be available. == How To Test == There is a test suite included in the acpica-tools package that is always run as part of the %check step in the spec file. No new testing should be required. == User Experience == Only s390x systems would notice a change in that this package would no longer be available. == Dependencies == The packages hw-probe, vim-syntastic-asl, and edk2 depend on acpica-tools. However, to make the changes to acpica-tools, there are no other dependencies. == Contingency Plan == * Contingency mechanism: do nothing; the existing f40 package can continue to be used. * Contingency deadline: beta freeze * Blocks release? No == Documentation == These changes actually put the Fedora version of the package back into a state where it matches upstream more closely. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

Planned Outage - wiki - 2024-06-18 21:00 UTC
by Kevin Fenzi 18 Jun '24

18 Jun '24

Planned Outage - wiki - 2024-06-18 21:00 UTC There will be an outage starting at 2024-06-18 21:00 UTC which will last approximately 2 hours. To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/Infrastructure/UTCHowto or run: date -d '2024-06-18 21:00UTC' Reason for outage: We will be upgrading the wiki to a newer version. During this outage the wiki will be down. Affected Services: https://fedoraproject.org/wiki Ticket Link: https://pagure.io/fedora-infrastructure/issue/11994 Please join #fedora-admin or #fedora-noc on irc.libera.chat or #admin:fedoraproject.org / #noc:fedoraproject.org on matrix. Please add comments to the ticket for this outage above. Updated status for this outage may be available at https://www.fedorastatus.org/

1 0

F41 Change Proposal: Nvidia Driver Installation with Secure Boot Support (self-contained)
by Aoife Moloney 17 Jun '24

17 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/NvidiaInstallationWithSecureboot Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-nvidia-driver-in… 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 == Nvidia Drivers have been removed from GNOME Software because it didn't support Secure Boot which is increasingly often enabled. This change brings the option back with Secure Boot supported. == Owner == * Name: [[User:eischmann|Jiří Eischmann]] * Name: Milan Crha * Email: eischmann(a)redhat.com * Email: mcrha(a)redhat.com == Detailed Description == The goal is this change is to provide an easy way to install Nvidia drivers in Fedora Workstation. It was removed from GNOME Software because the original mechanism didn't support Secure Boot. When users installed the drivers with Secure Boot enabled, they could not boot the OS. What we're doing this time is using mokutil to create a key for the user to self-sign the drivers. When installing the drivers, the user is asked to provide a password for the key. On the next reboot the user is presented with the mokutil interface to enroll the key. See the [https://gitlab.gnome.org/GNOME/gnome-software/-/merge_requests/2034 upstream merge request] for more details and screenshots. == Feedback == == Benefit to Fedora == The Nvidia drivers are necessary not only for gaming, but especially for CUDA and AI/LLM workloads. The Nvidia drivers can't be part of Fedora because of their license, but Fedora should offer an easy installation of them to stay relevant in the respective fields. == Scope == * Proposal Owners: The feature will be implemented in GNOME Software 47 and will be shipped in the gnome-software package in Fedora Linux 41. * Other Developers: No work required from other Fedora developers. The only requirement outside of the scope of the proposal owners is to reintroduce AppStream metadata into the Nvidia driver repo on RPMFusion.org. * Release Engineering: * Policies and Guidelines: * Trademark approval: * Alignment with Community Initiatives: == Upgrade/compatibility impact == No impact is expected. == How To Test == 1. Open GNOME Software. 2. Search for "nvidia". 3. Choose the Nvidia driver, click Install and follow the prompts. 4. Reboot and enroll the self-signing key in the mokutil tool following <<the documentation will be added>> 5. The OS should boot up with the Nvidia driver enabled. == User Experience == This change aims to improve user experience of installing the proprietary Nvidia driver. == Contingency Plan == If the feature is not implemented on time for Fedora Linux 41, we can simply remove AppStream metadata from the Nvidia driver repo and the driver will not show up in GNOME Software like in Fedora Linux 40. == Documentation == The GNOME Software part is intuitive and doesn't require documentation. The mokutil part is less intuitive and will be documented in the Fedora Workstation section on docs.fedoraproject.org. The docs will be published when the feature lands in Fedora Linux 41. == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F41 Change Proposl: Libvirt Virtual Network NFTables (self-contained)
by Aoife Moloney 17 Jun '24

17 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/LibvirtVirtualNetworkNFTables Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposl-libvirt-virtual-n… 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 == The default firewall backend for the default libvirt virtual network (the virbr0 bridge device), will change from 'iptables' to 'nftables'. == Owner == * Name: [[User:berrange| Daniel Berrange]] * Email: berrange(a)redhat.com == Detailed Description == A default installation of libvirt will create an isolated bridge device (virbr0), to which guest virtual machines can have their NIC connected. Firewall rules are used to provide NAT based connectivity on this bridge device, as well as allow access to the DNS/DHCP services provided by the dnsmasq it launches on the host. Historically libvirt has always used the iptables tools, which first talked to the iptables kernel modules, but in recent Fedora uses the nftables kernel modules. When Fedora switched Firewalld to use nftables for its own firewall rules, libvirt kept using its iptables userspace backend, which then indirectly created kernel nftables rules. To work correctly, libvirt added the ability to associate its bridge devices with a 'libvirt' zone in firewall to ensure guest->host DHCP/DNS/SSH traffic was not blocked by firewall. With this change, libvirt will now prefer to directly use the nftables userspace tools to create its firewall rules, where they are installed: * nftables only installed => libvirt uses its nftables backend * iptables only intsalled => libvirt uses its iptables backend * nftables and iptables installed => libvirt uses its nftables backend This default behaviour can be overridden to force a specific backend by editting settings in /etc/libvirt/network.conf. Note that this change only applies to libvirt's virtual network functionality. Libvirt's nwfilter (network filter) functionality is still exclusively using iptables/ebtables. This will be switched to nftables in a future Fedora release, timeframe to be determined. == Feedback == TBD == Benefit to Fedora == * Libvirt will be using the same recommended modern nftables userspace as firewalld instead of the legacy iptables compatibility tools which secretly talk to nftables behind the scenes. * All the libvirt nftables rules will be self-contained in a dedicated 'libvirt_network' nftables table, reducing the scope for other applications accidentally changing/removing them. * Improved performance scalability since libvirt's nftables rules are written to use an interface ID match which is a simple lookup, while traditional string based interface name matches in iptables require multiple string comparisons. == Scope == * Proposal owners: Change the libvirt RPM spec to set the 'nftables' backend as the preferred default * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == Existing hosts with libvirt deployed will be using iptables for their firewall rules. When the Fedora upgrade brings in the new libvirt, it will detect the switch to nftables and attempt to remove the historically created iptables rules, and create new nftables rules providing equivalent functionality. A number of iptables chains will remain present after an upgrade * Chain LIBVIRT_FWI * Chain LIBVIRT_FWO * Chain LIBVIRT_FWX * Chain LIBVIRT_INP * Chain LIBVIRT_OUT These chains should not contain rules and thus be harmless. They will go away permanently the next time the host is rebooted, or can be deleted manually if desired. === Reverting to iptables for compatibility === If an incompatibility is discovered between libvirt's nftables backend and some other use case, it is possible to tell libvirt to revert to its iptables backend. * Edit /etc/libvirt/network.conf and set 'firewall_backend = "iptables"' * systemctl restart virtnetworkd Libvirt should then automatically delete its nftables rules and create equivalent iptables rules as present on previous Fedora releases. Alternatively, if the 'nftables' userspace tools are not installed at all, libvirt will attempt to use the 'iptables' userspace tools instead, if present. === Known issue: docker === The Docker iptables integration force changes the iptables FORWARD chain policy from ACCEPT to DENY. This makes '''Docker incompatible with any application that is using nftables''' to try to allow forwarding: https://docs.docker.com/network/packet-filtering-firewalls/#docker-on-a-rou… When libvirt uses its iptables backend, its FORWARD rules will end up in the same table as docker's, and so override the DENY policy docker had created. When libvirt uses its nftables backend, its FORWARD rules end up in a separate table from dockers'. Since nftables requires a packet to be allowed by *all* top level tables, docker's DENY rules will block the libvirt traffic. The possible workarounds are: * Reconfigure libvirt to use iptables when compatibility with docker is required * Use podman instead of docker, since podman does not create problematic iptables rules * TBD: whether libvirt can do something automagic to workaround docker's DENY policy === Known issue: non-firewalld firewall mgmt tools === Libvirt requires the ability to mark traffic from the guest to the host, for DHCP and DNS as permitted. When using iptables kernel modules, libvirt could achieve this by inserting some rules in the INPUT chain to allow DHCP/DNS. When using nftables kernel modules, there are an arbitrary number of application defined top level tables with unknown names. All top level tables must allow a packet in order for it to pass. libvirt must not touch tables created by other applications, thus it is no longer practical to seemlessly allow DHCP & DNS when nftables userspace is used by any component on the system. To address this, when Fedora 32 switched firewall to its nftables backend, libvirt gained ability to install a firewalld zone files to allow guest traffic. Libvirt does not have equivalent integration for any other nftables based firewall mgmt tool, but other tools using iptables remained compatible as long as libvirt also kept using iptables. With libvirt changing to prefer its nftables backend, libvirt is will be incompatible with any other non-firewalld firewall management tools. The compatibility matrix is as follows # Kernel module: iptables, firewall mgmt userspace: iptables, libvirt backend: iptables => WORKS for all firewall mgmt tools # Kernel module: nftables, firewall mgmt userspace: iptables, libvirt backend: iptables => WORKS for all firewall mgmt tools # Kernel module: nftables, firewall mgmt userspace: iptables, libvirt backend: nftables => WORKS for firewalld, other tools require workaround # Kernel module: nftables, firewall mgmt userspace: nftables, libvirt backend: iptables => WORKS for firewalld, other tools require workaround # Kernel module: nftables, firewall mgmt userspace: nftables, libvirt backend: nftables => WORKS for firewalld, other tools require workaround The two main workaround options: * Change /etc/libvirt/network.conf 'firewall_backend' setting to 'iptables' * Manually add rules to the firewall mgmt tool to allow DHCP, DNS & SSH from guests. The long term answer is to enhance libvirt upstream to natively learn about integration for more firewall mgmt tools than just firewalld. eg UFW: https://gitlab.com/libvirt/libvirt/-/issues/644 == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == * Perform a default libvirt KVM install 'dnf groupinstall @Virtualization' * Create a KVM guest using virt-install, virt-manager, or cockpit, and configure it to use the 'default' virtual network * Boot the KVM guest * Login to the KVM guest graphical console, and attempt to connect to the internet. eg curl https://google.com * Configure the KVM guest to enable SSH (if not already allowed & started) * Attempt to SSH to the guest from the host == User Experience == * Libvirt firewall rules will no longer be present when running 'iptables -L' * A new 'libvirt_network' table will be present when running 'nft list ruleset' == Dependencies == None == Contingency Plan == * Contingency mechanism: Libvirt maintainers to change the libvirt.spec to set 'prefer_nftables' variable to '0' for Fedora 41 * Contingency deadline: Final freeze * Blocks release? No == Documentation == General libvirt network documentation at https://libvirt.org/formatnetwork.html == Release Notes == The libvirt virtual network has been changed to prefer use of the nftables firewall backend instead of iptables. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F41 Change Proposal: Confidential Virtualization Host with AMD SEV-SNP (self-contained)
by Aoife Moloney 17 Jun '24

17 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/ConfidentialVirtHostAMDSEVSNP Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-confidential-vir… 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 enables Fedora virtualization hosts to launch confidential virtual machines using AMD's SEV-SNP technology. Confidential virtualization prevents admins with root shell access, or a compromised host software stack, from accessing memory of any running guest. SEV-SNP is an evolution of previously provided SEV and SEV-ES technologies providing stronger protection and unlocking new features such as a secure virtual TPM. == Owner == * Name: [[User:berrange| Daniel P. Berrangé]] * Email: berrange(a)redhat.com == Detailed Description == Fedora has provided support for launching confidential virtual machines using KVM on x86_64 hosts for several years, using the SEV and SEV-ES technologies available from AMD CPUs. These technologies have a number of design limitations, however, that make them less secure than is desired, and prevent exposure of desirable features such as secure TPMs. The SEV-SNP technology is a significant design enhancement and architectural change to addresses the key gaps, increasing security and unlocking more powerful use cases for confidential virtual machines. With SEV/SEV-ES, attestation of the launched VM has to be initiated from the host, which means for a guest owner to attest their VM, they need to rely on API services exposed by the virtualization management stack which will vary across applications. With SEV-SNP, guest owners can initiate attestation from within guest context, providing a standard mechanism across any virtualization environment running SEV-SNP, avoiding a reliance on any host platform tools/APIs. The SEV-SNP technology also unlocks the ability to have a paravisor run in guest context, which is a miniature OS that runs at a higher privilege level (VMPL 0) than the guest firmware / OS (VMPL 3). The paravisor, specifically the [https://github.com/coconut-svsm/svsm Coconut SVSM] implementation, is able to expose trusted services to the guest firmware and OS, which also remain inaccessible to the host. This makes it possible to provide a secure virtual TPM for confidential guests, thus allowing guest OS software to be better secured than is the case with normal virtual TPMs running in host OS context. == Feedback == * TBD == Benefit to Fedora == Confidential guests running under a Fedora SEV-SNP enabled KVM host will be able to: * Self initiate an VM attestation to prove integrity of their running guest machine. This guarantees their guest is running on AMD hardware with SEV-SNP setup in a given configuration, running a particular build for EDK2 firmware, providing data confidentiality even if the host is compromised or malicious. * Measure all aspects of the guest machine boot process into PCRs in a securely hosted virtual TPM * Protect against various known weaknesses of the traditional SEV and SEV-ES technologies == Scope == === Proposal owners === * Ensure kernel packages built in Fedora have SEV-SNP feature integrated and enabled. Code is in kvm/next tree, targetted to merge to linus's tree when 6.11 merge window opens. Will require backport to Fedora's 6.10 tree. * Ensure QEMU packages built in Fedora have SEV-SNP feature integrated and enabled. Queued for merge into the forthcoming [https://wiki.qemu.org/Planning/9.1 9.1.0 upstream release] - rc0 Jul 30th, GA Sep 3rd. F41 beta will ship a QEMU rc, and F41 GA will have QEMU GA release. * Ensure libvirt packages built in Fedora have SEV-SNP feature integrated. Targeted to release immediately following merge into QEMU git HEAD. Releases on 1st of each month, anticipated Sept 1st release at latest, version 10.7.0, but ideally Aug 1st release. * Ensure EDK2 packages built in Fedora have a EFI binary built suitable for use with SEV-SNP guests with SVSM paravisor. EDK2 currently in rawhide has support for SNP + SVSM. Only lacking vTPM support. * Add new Coconut SVSM package, to provide paravisor for SEV-SNP guests. Work in progress adding required rust deps. * Add new IGVM library package, to enable bundling of Coconut SVSM and EDK2 firmware into one launch binary. Work in progress adding required rust deps. * Ensure that an IGVM binary is built containing paired EDK2 and SVSM binaries. * Ensure that virt-install is able to launch an SEV-SNP guest with SVSM and EDK2 === Other developers === * Kernel maintainers: responsible for building new kernel that includes SEV-SNP feature. Currently code is in kvm/next tree, targetted for linus' tree when the 6.11 merge window opens. '''ONLY''' if it merges to linus' tree, then proposal owners are to provide Fedora kernel maintainers with a set of backported patches against 6.10 prior to Fedora Beta. Fedora 41 will get 6.11 kernels after GA. === Release engineering === N/A === Policies and guidelines === N/A === Trademark approval === N/A === Alignment with the Fedora Strategy === * Fedora will be demonstrating leading / state of the art integration of SEV-SNP feature into a Linux distribution's virtualization host stack. * Fedora will be providing the fully OSS host-to-guest stack for confidential virtual machines on modern AMD x86_64 EPYC hardware. == Upgrade/compatibility impact == No impact anticipated. Existing users of SEV/SEV-ES technology will keep using it without changes. The new SEV-SNP technology is strictly an opt-in for users with suitably new AMD CPUs. == Early Testing (Optional) == Do you require 'QA Blueprint' support? Y (probably useful?) == How To Test == Use of AMD SEV-SNP technology requires an AMD EPYC CPU with the Zen 3 generation micro-architecture, or newer (Milan, Genoa). These are identified by the 4th digit in the processor model name having the value '3' or greater. eg EPYC7xx3 or EPYC9xx4. See also [https://www.amd.com/content/dam/amd/en/documents/epyc-technical-docs/tuning… SEV User Guide (pdf), Chapter 1] for CPU model support guidance. * TBD: document process for configuring host bare metal firmware (if applicable?) * TBD: document process for deploying host software components. Likely should not require any special steps, beyond the normal libvirt + KVM install process. * TBD: document process for creating a guest. Will update existing [https://libvirt.org/kbase/launch_security_sev.html libvirt SEV docs] to cover SEV-SNP * TBD: document process for attesting a running guest. Again, will update above libvirt SEV docs. == User Experience == * Virtualization host owners will be launch confidential virtual machines using AMD SEV-SNP technology * Virtualization host owners will be able to provide a secure virtual TPM to confidential guests, replacing the current non-confidential swtpm solution in the host * Guest owners will be able to prove that their OS is running in a Fedora host confidential virtual machine protected by AMD SEV-SNP, by performing a guest attestation * Guest owners will be able to measure their guest OS software environment using the TPM. Caveat: this is an ephemeral TPM initially, which imposes limits on the ways in which users can take advantage of it. A persistent TPM will be supported at a later date. == Dependencies == * kernel * edk2 * coconut-svsm (new package [https://github.com/coconut-svsm/svsm github upstream]) ** rust-intrusive-collections (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290692 Review Request]) ** rust-packit (new package or include as vendored) * igvm (new package [https://github.com/microsoft/igvm/ github upstream]) ** rust-hmac-sha512 (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290698 Review Request]) ** rust-bitfield-struct (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2290696 Review Request]) ** rust-open-enum (new package) ** rust-open-enum-derive (new package) ** rust-range-map-vec (new package, [https://bugzilla.redhat.com/show_bug.cgi?id=2282977 Review Request]: Approved) * qemu * libvirt * virt-manager (for virt-install tool) * snphost [https://github.com/virtee/snphost github upstream] * snpguest (new package, [https://github.com/virtee/snpguest github upstream]) == Contingency Plan == * Contingency mechanism: None. All the work is arriving either via rebases to new upstream versions of existing packages, patches to existing packages, or via new package reviews. If the deadline is missed, then whatever has already arrived in Fedora will remain in Fedora and will not harm other existing Fedora functionality. The remaining pieces will wait until the next Fedora dev cycle to be integrated, completing the desired user experience. As such, no contingency action needs to be taken should the Fedora feature completion deadline be missed. * Contingency deadline: N/A * Blocks release? No == Documentation == * Insert link to kernel docs, when available * Insert link to QEMU docs, when available * Insert link to libvirt docs, when available * Write a Fedora wiki page illustrating end-to-end setup and usage example == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F411 Change Proposal: KDE Plasma Mobile Spin and Fedora Kinoite Mobile (Self-Contained)
by Aoife Moloney 17 Jun '24

17 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_Plasma_Mobile Discussion Thread - https://discussion.fedoraproject.org/t/f411-change-proposal-kde-plasma-mobi… 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 == A Fedora Spin using KDE Plasma Mobile and a Fedora Kinoite Mobile Bootable Container image. == Owner == * SIG: [[SIGs/KDE|KDE SIG]] * Name: [[User:tdawson| Troy Dawson]] * Email: tdawson(a)redhat.com * Name: [[User:ngompa| Neal Gompa]] * Email: ngompa13(a)gmail.com * Name: [[User:Siosm| Timothée Ravier]] * Email: travier(a)redhat.com == Detailed Description == Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile brings its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops. We propose to create a Fedora KDE Plasma Mobile spin and the corresponding Atomic variant: Kinoite Mobile (only Bootable Container images, no classic ostree variant). == Feedback == Feedback has been positive thus far. As KDE Plasma Mobile has taken shape in Fedora, more and more people have asked for a spin so it is easier to setup on their machines. == Benefit to Fedora == KDE Plasma Mobile will give Fedora a strong showing in the mobile market. Many other distributions that targeted the mobile market have concentrated on cellphones. We believe that by targeting all touchscreen devices, we can bring more users into the Fedora community. == Scope == * Proposal owners: ** '''Spin configuration:''' ** '''Work with RelEng to build:''' ** '''Test Day coordination:''' * Other developers: N/A * Release engineering: Will submit issue once this is approved. [https://pagure.io/releng/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: Will submit issue once this is approved. * Alignment with the Fedora Strategy: Yes. == Upgrade/compatibility impact == N/A (not a System Wide Change) == How To Test == Proper Fedora KDE Plasma Mobile Spin: 1. Boot the Fedora KDE Plasma Mobile Spin ISO image either on bare-metal or in a virtual machine (V.M.). 2. Confirm successful boot into a configured KDE Plasma Mobile environment with basic packages available. 3. Launch Anaconda installer. 4. Confirm no major issues with windows and display. The installed system uses sddm as the login manager and comes preinstalled with KDE Plasma Mobile as the default desktop environment and with default applications present for most use cases. Repeat with Kinoite Mobile. == User Experience == Users are able to consume KDE Plasma Mobile from https://spins.fedoraproject.org instead of installing another desktop and then manually installing KDE Plasma Mobile after the initial installation. Similarly for Kinoite Mobile. The Spin should remain as minimal as possible and only include small supplements on top of making the default configuration workable. We should make the user experience as easy and simple as possible without defining too many opinions. == Dependencies == N/A (not a System Wide Change) == Contingency Plan == * Contingency mechanism: Push this off to the next Fedora release * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == N/A (not a System Wide Change) == Release Notes == This release brings the Fedora KDE Plasma Mobile Spin and its corresponding Atomic variant: Kinoite Mobile. Built on the foundations of KDE Plasma Desktop, KDE Plasma Mobile and Kinoite Mobile bring its flexibility to a mobile form factor. Although originally geared towards phones, the touch friendly interface works very well on tablets and 2-in-1 laptops. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 1

F41 Change Proposal: Replace Nose With Pynose (self-contained)
by Aoife Moloney 17 Jun '24

17 Jun '24

wiki - https://fedoraproject.org/wiki/Changes/ReplaceNoseWithPynose Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-replace-nose-wit… 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 == Package <code>python-nose</code> was [https://fedoraproject.org/wiki/Changes/DeprecateNose deprecated] in Fedora 32. It’s official successor, [https://github.com/nose-devs/nose2 <code>nose2</code>] does not provide all the functionality of <code>nose</code>. However, [https://github.com/mdmintz/pynose <code>pynose</code>] does and thus can be used as a drop-in replacement for <code>nose</code> allowing us to retire <code>python-nose</code>. == Owner == * Name: [https://fedoraproject.org/wiki/User:gui1ty Sandro] * Email: gui1ty(a)penguinpee.nl == Feedback == There are still a few (~70) packages in Fedora depending on deprecated <code>python3-nose</code> for their tests. Other packages have been switched to <code>python3-pytest</code> when nose was deprecated or migrated to <code>python3-pynose2</code>. As efforts are underway to upgrade <code>python3-pytest</code> to version 8.x.y, it turns out this version no longer supports running nose setup/teardown functions/methods, thereby breaking packages that still rely on those functionality. Since pynose is using the same namespace as deprecated nose, with a minor hack<ref>[https://src.fedoraproject.org/fork/gui1ty/rpms/python-pynose/c/594c580ae126… nose metadata hack]</ref>, the package can be modified to provide a proper replacement for <code>python3-nose</code> with regards to the RPM as well as the Python metadata. Pynose also provides the same set of executables. So packages still running <code>nosetests</code> will be able to switch seemlessly to <code>python3-pynose</code> in [https://copr.fedorainfracloud.org/coprs/gui1ty/pynose-nose/builds/ most cases]. Packagers can also decide to switch their packages manually by simply changing to <code>python3-pynose</code>, which is currently available in rawhide. == Benefit to Fedora == Providing pynose as a drop-in replacement for nose will allow us to retire long deprecated <code>python-nose</code> without forcing any packages still depending on it to go look for an alternative or be retired. It will also assist in the efforts of upgrading pytest to version 8 by allowing packages that still rely on nose setup/teardown functions/methods to switch back to <code>nosetests</code> provided by pynose. == Scope == * Proposal owners: Provide <code>python3-pynose</code> as a drop-in replacement for <code>python3-nose</code>; provide PRs for packages that need adaption; provide help * Other developers: Manually switch to depending on <code>python3-pynose</code> if desired; switch back to <code>nostests</code> if adapting to pytest 8 proves difficult * 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 Community Initiatives: == Upgrade/compatibility impact == Transitioning from nose to pynose will happen behind the secenes. Packages now depending on <code>python3-nose</code> or <code>python3dist(nose)</code> will have that dependency satisfied by <code>python3-pynose</code> instead of <code>python3-nose</code>. Where packages need to be adapted, PRs will be provided to make them work with pynose. == How To Test == Packagers can test their package using the [https://copr.fedorainfracloud.org/coprs/gui1ty/pynose-nose/ Copr repo]. # <code>copr mock-config gui1ty/pynose-nose fedora-rawhide-x86_64 > ~/.config/mock/pynose-nose-rawhide.cfg</code> # <code>fedpkg --release rawhide mockbuild --root pynose-nose-rawhide</code> Let us know if you need help. == Dependencies == Packages currently build requiring <code>python3-nose</code>: * binwalk * bmap-tools * hgsvn * mod_nss * nova-agent * odcs * openms * ProDy * pydot * pytest * python-agate * python-agate-dbf * python-agate-excel * python-agate-sql * python-anyjson * python-axolotl * python-behave * python-binstruct * python-blessings * python-boto * python-case * python-colorspacious * python-curtsies * python-deap * python-epc * python-etcd * python-eyed3 * python-fedmsg-meta-fedora-infrastructure * python-flask-xml-rpc * python-fluidity-sm * python-gensim * python-hglib * python-http-ece * python-httpretty * python-ifcfg * python-inflect * python-ipmi * python-iptools * python-ipython_genutils * python-jenkins * python-leather * python-mapnik * python-migrate * python-moksha-common * python-moksha-hub * python-musicbrainzngs * python-neurosynth * python-nitime * python-ofxparse * python-ordered-set * python-pycdio * python-pygatt * python-pygeoip * python-pypillowfight * python-pyramid-tm * python-pytest-mpl * python-pytimeparse * python-queuelib * python-rows * python-sievelib * python-simplebayes * python-spec * python-spur * python-statsd * python-stomper * python-supersmoother * python-tilestache * python-www-authenticate * python-xvfbwrapper * vigra == Contingency Plan == * Contingency mechanism: 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 == [https://github.com/mdmintz/pynose/blob/master/README.md pynose README] and above == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F41 Change Proposal: GIMP Version 3 (self-contained)
by Aoife Moloney 17 Jun '24

17 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/Gimp_3 Discussion Thread - https://discussion.fedoraproject.org/t/f41-change-proposal-gimp-version-3-s… 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 introduces the upcoming major version 3 of the GNU Image Manipulation Program in Fedora Linux. == Owner == * Name: [[User:Nphilipp| Nils Philippsen]] * Email: nphilipp -at- redhat.com (or nils -at- tiptoe.de) == Detailed Description == The [https://gimp.org GIMP project] intends to release the [https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap major version 3] of the GNU Image Manipulation Program [https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline later this year]. This new version involves substantial changes to the technologies used, which in turn means that third party plugins have to be ported to be compatible. Therefore, this change will add the new version as a new package <code>gimp3</code> which can be installed side-by-side with the existing version 2.x package, so people can continue working on existing projects with the old gimp version and its plugins. In order to make upgrades seamless for users (and avoid having to go through an exception process for a “new” <code>gimp2</code> package needing Python 2.x), the existing package will remain named <code>gimp</code> and it plus <code>gimp3</code> will obsolete the version 2.x packages from Fedora Linux <= 40 in version 41. == Feedback == Alternative proposals were made, e.g. in [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… the respective thread on the devel mailing list]: * ''Replacing version 2 with version 3 wholesale, without possibility for parallel installation, starting in Fedora Linux 41.'' This would force users to choose between using either using version 2.x or 3.x of GIMP, and it might make users with existing GIMP projects stay longer on an older version of Fedora Linux than they would do otherwise. * ''Add <code>gimp2</code> for the old version, let <code>gimp</code> become version 3 in Fedora Linux 41 …'' This would need an exception for the <code>gimp2</code> package, as it needs Python 2.x. ** ''… and introduce version 3 as <code>gimp3</code> in Fedora Linux <= 40.'' This would come along with even more packaging churn, it would introduce <code>gimp3</code> only for two existing Fedora versions and then obsolete the package, also makes the upgrade obsolete dance from 40 to 41 more complicated than it needs to be. ** ''… and only introduce GIMP version 3 in Fedora Linux >= 41.'' This would withhold the benefits of the new GIMP version to users of older Fedora Linux versions without a technical need to do so. == Benefit to Fedora == This change upgrades GIMP to a version which doesn’t use ancient 2.x versions of both GTK and Python anymore. Other than many new features including better color management and the support of CMYK import/export, it greatly improves user experience with certain input devices such as tablets and on displays with very high resolutions. Developers of plugins using Python can now use packages and language features which simply don’t exist in Python 2.x. == Scope == * Proposal owners: ** Make (pre-releases) available as <code>gimp3</code> in Rawhide and existing Fedora Linux versions. ** Ensure users of <code>gimp</code> get both versions when upgrading their OS to Fedora Linux 41. ** Ensure comps is updated to refer to the new GIMP version from Fedora Linux 41 on. * Other developers: Maintainers of third party plugins work with their respective upstreams to either find out if they have been ported to GIMP 3.x, or assist in porting and make such ports available in Fedora. * Release engineering: This is a self-contained change and doesn’t require that release engineering is involved. * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This change doesn’t particularly relate to the [https://discussion.fedoraproject.org/t/fedora-strategy-2028-february-march-… the current Fedora Strategy], but it aligns well with “Freedom”, “Features” and maybe ”First” of the [https://docs.fedoraproject.org/en-US/project/#_what_is_fedora_all_about Fedora Foundations]. == Upgrade/compatibility impact == The plan is that existing users of <code>gimp</code> end up with both this package and the new version as <code>gimp3</code>. It should be possible to install either version without pulling in the other on Fedora Linux >= 41 (if technically feasible). == User Experience == With Fedora Linux 41, users who install GIMP as an RPM package will get the new version by default. It contains many new features and improvements in the handling of input devices such as tablets and when used on high resolution displays. == Dependencies == A number of third party GIMP plugins are available to be installed as packages on Fedora Linux. With the continued availability of version 2.x of GIMP, these packages can still be installed and used with the old version. Whether or not these plugins will support the new GIMP version very much depends on the particular plugin, or rather the upstream projects for these plugins. Therefore it’s a bit early to make plans for packaging plugins available for both GIMP versions at this point. == Contingency Plan == * Contingency mechanism: Not ship the package, bump “seamless update” measures to be effective in Fedora Linux 42. * Contingency deadline: Beta Freeze * Blocks release? No == Documentation == * https://gimp.org/ * https://developer.gimp.org/core/roadmap/#gimp-30-development-branch-roadmap * https://gitlab.gnome.org/GNOME/gimp/-/issues/10373#timeline == Release Notes == This release of Fedora Linux ships version 3 of the GNU Image Manipulation Program, with many new features and improved user experience. The package is called <code>gimp3</code>, the old version will still be available under the old name, <code>gimp</code> for users who need it for existing projects. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

F41 Change Proposal: Mark Fedora KDE AArch64 as Release-Blocking (System-Wide)
by Aoife Moloney 17 Jun '24

17 Jun '24

Wiki - https://fedoraproject.org/wiki/Changes/Fedora_KDE_AArch64_ReleaseBlocker Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-mark-fedora-kde-… 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 == Mark Fedora KDE AArch64 deliverables as release-blocking, leveraging the same criteria for Fedora on AArch64 and Fedora KDE on x86_64. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngompa13(a)gmail.com == Detailed Description == The Fedora KDE SIG already considers Fedora KDE on AArch64 at the same level of importance as Fedora KDE on x86_64, and the SIG wants the Fedora KDE AArch64 deliverables (such as the disk images and ISOs) to be release-blocking alongside existing Fedora KDE x86_64 deliverables. == Feedback == == Benefit to Fedora == This allows the Fedora KDE SIG to reinforce its commitment to the highest quality KDE Plasma experience on Fedora possible on AArch64 like on x86_64, and it lets Fedora better support the larger ecosystem around Fedora leveraging KDE Plasma (of one notable member being the Fedora Asahi Remix). == Scope == * Proposal owners: Update pungi-fedora to mark AArch64 artifacts as release blocking ([https://pagure.io/pungi-fedora/pull-request/1290 pagureio#pungi-fedora#1290]) * Other developers: N/A (not needed for this Change) * Release engineering: [https://pagure.io/releng/issue/12165 #12165] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: This aligns with expanding and improving Fedora's connections to the larger ecosystem by supporting upstream KDE with our expertise on AArch64 and downstream distributions like the Fedora Asahi Remix using Fedora KDE on AArch64. == Upgrade/compatibility impact == This has no impact on users. == How To Test == Fedora KDE can be tested on AArch64 the same way Fedora Workstation is: * Fedora KDE AArch64 ISO on either QEMU/KVM or a device with UEFI CD boot such as [https://github.com/pftf the Raspberry Pi using UEFI firmware] * Fedora KDE AArch64 raw disk image on existing supported AArch64 devices == User Experience == This does not change anything for the user experience. == Dependencies == There are no extra dependencies. == Contingency Plan == * Contingency mechanism: Revert release-blocking status for Fedora KDE on AArch64 * Contingency deadline: Final Freeze * Blocks release? Yes == Documentation == There is no user-facing documentation to update. Fedora QA documentation on release-blocking artifacts will note Fedora KDE AArch64 artifacts as release-blocking. == Release Notes == Not applicable as this is not a user-facing Change. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce