CVE-2024-2905: World-readable /etc/shadow & /etc/gshadow on Fedora CoreOS, IoT, Atomic Desktops
Due to a bug in rpm-ostree, the /etc/shadow, /etc/shadow-, /etc/gshadow and /etc/gshadow- files in Fedora CoreOS, IoT, Atomic Desktops have the world-readable bit set. == Affected versions == All Fedora CoreOS nodes installed starting from the following versions are impacted: - stable: 38.20230902.3.0 - testing: 38.20230902.2.1 - next: 38.20230902.1.1 Fedora IoT and Fedora Atomic Desktops (Silverblue, Kinoite, Sway Atomic, Budgie Atomic) systems that were installed from Fedora 39 and later release media and ISOs are affected. This only impacts new installations and not updated systems thus systems installed from artifacts before those releases are not impacted (Fedora 38 or earlier). This only impacts systems where a password is set. Systems where only SSH keys were used are not impacted by this vulnerability even though it is present on the node. On systems with SELinux enabled and in enforcing mode, access to those files is limited to unconfined (usually interactive) users, unconfined systemd services and privileged containers. Confined daemons, users and containers are not able to access them. == Fixed versions == The following Fedora CoreOS versions fix the issue and include a systemd unit to fix existing systems on update: - stable: 39.20240322.3.1 - testing: 39.20240407.2.0 - next: 40.20240408.1.0 Fedora CoreOS systems with automatic updates enabled will automatically get the update starting on 2024-04-10 14:00 UTC. Fedora Atomic Desktops version 39.20240410.1 includes the fix. The fix is still pending for Fedora Atomic Desktops 40 (not officially released yet). An update with the fix for Fedora IoT is still pending. == Workaround / immediate fix == To immediately fix existing systems, you can run the following command as root: chmod --verbose /etc/shadow /etc/gshadow /etc/shadow- /etc/gshadow- As a precaution, we recommend rotating all user credentials stored in those files. == References == GitHub Security Advisory: https://github.com/coreos/rpm-ostree/security/advisories/GHSA-2m76-cwhg-7wv6 Red Hat Security Advisory: https://access.redhat.com/security/cve/CVE-2024-2905 Fedora CoreOS issue: https://github.com/coreos/fedora-coreos-tracker/issues/1705 -- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F40 Change Proposal: Dropping sshd.socket file (Self Contained)
Posting here what I've posted to the Forum thread. https://github.com/systemd/systemd/pull/29159 has been merged in systemd upstream and should address the main concerns I had raised in https://bugzilla.redhat.com/show_bug.cgi?id=2025716#c0. I don't think we should do this change anymore. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
> Would these messages show up, for example, if they opened the terminal app? They only show up on the console / ssh login prompt if I'm not mistaken: https://github.com/fwupd/fwupd/tree/main/data/motd ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F39 Change Proposal: Enable fwupd-refresh.timer by default on IoT, CoreOS & Server Editions (Self-Contained)
> Actually, why wouldn't this be used everywhere? I could see this be > useful when people remote into workstations and apply updates. I know > of plenty of people that split their desktops between local and remote > access/administration. We could enable it everywhere but we've not reached out to desktop editions for comments. Process wise, that could potentially move this Change from Self Contained to System Wide. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
Working on having a better Firefox shipped as a Flatpak by default will please a lot of people that as asking for Firefox to be removed from the base image: https://github.com/fedora-silverblue/issue-tracker/issues/288 If we can have Cisco host a container image with openh264 as a Flatpak extension then that would be great as the extension would be pulled down automatically during flatpak update. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
The main issue with this change for Silverblue/Kinoite is that this introduces client side layering by default for all users. To understand why this is not a good idea, I need to recap a few things: how rpm-ostree client side layering works, the general goal behind rpm-ostree and image based updates and what we're trying to do in https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. First, let's start with rpm-ostree client side layering. When you update a "pristine" Silverblue system, the following happens: 1. rpm-ostree looks into the remote ostree repo for the latest version commit and downloads all the files needed for it into the local repo. 2. Once this is done, it creates a new deployments, which is a new copy of /usr made mostly of hardlinks to the repo. 3. Then you can reboot and you're done. When you enable client side layering, because you want to change something in the image, remove a package, add a new one, etc., the following happens: 1. rpm-ostree has to fetch the needed files into the repo like in the previous case (step 1). 2. But then, instead of creating directly creating a new deployment, it creates a temporary one with the content of the latest commit. 3. From this temporary deployment, rpm-ostree is able to fetch all RPM metadata from the Fedora repos, then resolve the dependencies for the added/replaced/removed packages and download the RPMs as needed. 4. It will then create a temporary writable overlay on top of the temporary deployment, perform the package installations, replacements, removals and optionally rebuild the initrd. 5. Then it will process the files in this overlay to create a new ostree commit. 6. Finally, it will deploy this new commit into a new deployment to be used after a reboot. Given the additional steps required when client side layering is used, updates will take longer to be downloaded, prepared and installed and will require more CPU and memory. Additionally, any operation done on the temporary deployment may fail: missing dependencies, conflicts, wrong package signatures, etc. The idea behind rpm-ostree hybrid model is that you don't have to manage package conflicts, installation, etc. on the client side and instead rely on the server composing a working image for you. With client side layering, this guarantee goes away and the user will have to intervene when it fails. This is the main reason why we recommend to be careful with client side layering: it may fail and you'll have to figure out why, just like you need to figure out dependency resolutions issues on a classic DNF based system. The main goal of Silverblue is to get rid of this issue in the first place by relying only on images by default. Users may choose to override things in the image but they would have to do that on purpose, via the command line, hopefully knowing that they are now responsible when something fails. Note that neither GNOME Software nor Plasma Discover support managing client side layered packages right now. GNOME Sofware pre-downloads packages, essentially making the first step invisible to the user and only then notifies the user to trigger the 2nd and 3rd steps. Plasma Discover is not yet capable of doing that but I'm working on it. So yes, client side layering is fully supported in Silverblue/Kinoite as it enables debugging, testing, workarounds, etc. but we don't want to expose users to it by default as this is not a good user experience. One solution to reduce the time taken by client side layering and those issues mentioned above is to move the package overrides back to the server side by using a layering approach similar to the one used to build containers. This is the goal of this change: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable. It enables users to make custom builds of Silverblue/Kinoite with their own selection of packages and changes and then to distribute them as an image to their systems, getting the full benefits of pure image based updates back if they don't do any local changes anymore. I hope that explained things in more details. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Non-responsive maintainer for lz4 package (pjp)
Hey folks, I've started the non-responsive maintainer procedure for pjp (https://accounts.fedoraproject.org/user/pjp/) with https://bugzilla.redhat.com/show_bug.cgi?id=2152159 I currently have a pull request that has been blocked for 4 months now: https://src.fedoraproject.org/rpms/lz4/pull-request/5 I have not checked if other pull requests or bugs are blocked. fedora-active-user (https://github.com/pypingou/fedora-active-user) reports the last action as: ``` Last action on koji: Fri, 09 Sep 2022 tag_package_owners entry created by humaton [still active] ``` I'll CC this mail to him but if you know how to reach him that will be best. Thanks! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
> On Fri, Dec 9, 2022 at 8:23 AM Timothée Ravier wrote: > Adding network-online.target is not hard, I could do that easily > enough. I would need to change the way the service starts to use a > flag instead of purely relying on firstboot mode though, since I can't > make firstboot run on, well not firstboot if I rely on systemd > firstboot. It's likely that network-online.target won't be enough on first boot if the network has not been setup in Anaconda and for EOM installations, it won't be as far as I know. I don't remember if GNOME initial setup does it or not. So you'll indeed have to try again multiple times on next boots. But how many times should it retry? If the system is never connected to the internet, should it do that every boot? That's starting to become a lot of logic for a Bash script that runs as root and performs package changes. If not in the initial setup, it could also be added to GNOME Software. In KDE in the welcome app or in Plasma Discover. > Mutating the system is sort of the point? I could just make it a no-op > for Silverblue/Kinoite, but the Workstation WG wanted it universally > applicable, so I did that legwork. We need another solution for Silverblue/Kinoite to setup those libraries post installation without relying on layering. On Silverblue & Kinoite, updates are fast when there are no package layered. If we layer a package on all installations by default, then we just make updates slow for everyone. Note that a lot of users also don't use the browser as installed in the system (we get a lot of complains about that) and install their own instead and thus won't benefit from that change. Existing/upgrading users also won't benefit from it. Using layering will also conflict / not interact well with the move to container based ostree image in F38: https://fedoraproject.org/wiki/Changes/OstreeNativeContainerStable > Aside from GNOME and KDE Plasma, nobody has an initial setup > interface. We'd have to do this in Anaconda's initial setup wizard. I > would have to build a dedicated application instead, which would > displease everyone. :) This is not the first (and won't be the last) feature that won't have an interface on non GNOME/KDE desktops. We also have https://docs.fedoraproject.org/en-US/workstation-working-group/third-party-repos/ which is set up on first boot in GNOME Initial Setup and thus not setup on KDE desktops right now. Thus I'm not sure that this should be blocking us. --- Overall, I won't oppose adding that for DNF based variants of Fedora if the working groups / desktops spin SIGs are fine with all those constraints. For Silverblue & Kinoite, I think we need another solution. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Add Fedora Auto Firstboot Services to desktop variants (System-Wide Change proposal)
Sorry I'm late here but while I agree with the idea, I don't think the implementation is done at the right level. As currently implemented, this will likely fail as the network won't be available / ready: https://pagure.io/fedora-autofirstboot/blob/main/f/systemd/fedora-autofirstboot.service This will also mutate rpm-ostree based systems on first boot (Silverblue & Kinoite), losing all the benefits of using a single image for everyone and making the update slower for everyone by default. I think that this is better implemented in a per-desktop app on first session startup on in the GNOME initial setup interface or corresponding project for other desktops. Having that done in a user visible interface will also surface errors where in this current implementation, any error will mostly be silently ignored. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: Starting Flatpak SIG
> Please put your name in https://fedoraproject.org/wiki/SIGs/Flatpak if > you are interested and I'll try to organize a poll for a weekly meeting > time. I'd suggest to start the meetings on the second week of January > when the holidays are over. Done! Thanks for starting that. > Some questions I have around organization: Can someone help register the > #fedora-flatpaks IRC channel under the Fedora umbrella? I am not sure > how to best do that. Does matrix need any special sauce to get a room? If possible, as this is a new channel, I'd recommend going Matrix only. This makes things simpler. > What would be a good name for a pagure.io project? > pagure.io/fedora-flatpaks or pagure.io/fedora-flatpak-sig or > pagure.io/flatpak-sig or something else? Voting for: pagure.io/fedora-flatpak group name with a SIG repo to track issues. > Do we need a mailing list? My initial gut feeling is no, but I'm > interested in what other people think. I think we don't. Tracking conversations and issues is much easier with a tracker than mailing lists. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)
Thanks, updated ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
Thanks, updated. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
> No, the install script install script in an RPM trigger, so the write is > still carried out by RPM. > > I don't agree. Just because a user can mess with files on the system > doesn't mean the rpmdb is a lie, nor is it reasonable to go recheck all > paths on the filesystem just in case they've done so, or create a daemon > to provide an interface for doing that. Note that this change here is only about Fedora Silverblue & Kinoite (and maybe IoT later). In those variants, /usr is read only and not expected to be changed by users. The rpmdb is thus pretty much guaranteed to match the content of the system by design for /usr. On rpm-ostree based systems, system composes (image builds), package installation and updates are done "offline" so /boot is not available. The bootloader is not updated by an RPM trigger and this is why we need an additional tool to perform the update at another time. We've created a daemon because we need the update to be reliable so it should not fail if your SSH connections fails or if you Ctrl-C it in the middle, etc. This daemon is really small and socket activated so it's mostly never running. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)
Good point. We'll have to do that indeed. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 proposal: Remove initial-setup from KDE Spin & Kinoite (Self-Contained Change proposal)
We'll need to investigate this option. I've added it in https://pagure.io/fedora-kde/SIG/issue/243 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
> Bootloaders are not single files. Consider UEFI: > > For grub2, there's both a .efi and some configuration that I'll handwave > for purposes of this conversation. For shim, it's more like 4 things - > the main shim*64.efi, fallback.efi, boot.efi, and boot.csv. These all > serve different purposes, and need to get loaded from specific parts of > the ESP. (Recall here that fat32 doesn't have symlinks, either.) I don't think I understand the problem here. Do shim updates usually change all of those files at once? What's blocking us from updating them one by one? Note that bootupd is not trying to solve the "safe" part of bootloader updates: we're aware that the system should not crash while the bootloader is being updated. See https://github.com/coreos/bootupd#questions-and-answers Thus that's why we're requiring interactions from an admin to apply the update as only they can now when the system is the less likely to crash. > While I think it will surprise no one that I don't agree with doing so, > bootupd claims the additional goal of supporting Legacy BIOS. For that, > you also need to consider updates to the MBR, which isn't a file at all. While we do have that as a goal, we don't support legacy BIOS right now thus the reason why this proposal is focusing on EFI systems: https://github.com/coreos/bootupd/issues/53 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
moby-engine (also known as Docker) maintenance in Fedora
Hi everyone, The moby-engine package [1] (also known as Docker) has been orphaned in Fedora and is looking for a new maintainer. The waiting period will soon be over and the package will be retired if nobody steps in. This means that the package will be unavailable starting with the next release of Fedora (Fedora 38) that should happen in approximately 5 to 6 months. If you are using this package and are interested in helping maintaining it, now is the time to come forward! This notably impacts Fedora CoreOS as we are including the moby-engine package by default to let users pick their container engine of choice whithout deciding for them in advance. We offer both major container engines by default in the image (podman and moby-engine). If the moby-engine package ends up being retired for Fedora 38, then we will have to recommend to its users on Fedora CoreOS that they either switch to the official Docker packages [2] or move to containerd or podman when the rebase to Fedora 38 happens alongside the Fedora 38 release [3]. Note that we will likely not remove the containerd package from Fedora CoreOS as it is still maintained in Fedora and is currently used by Kubernetes distributions based on Fedora CoreOS (such as Typhoon for example). See also the Fedora CoreOS tracker issue [4] for more details. [1] https://src.fedoraproject.org/rpms/moby-engine [2] https://docs.docker.com/engine/install/fedora/ [3] https://fedorapeople.org/groups/schedule/f-38/f-38-key-tasks.html [4] https://github.com/coreos/fedora-coreos-tracker/issues/1291 Thanks, Timothée Ravier for the Fedora CoreOS team ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
If I understood things correctly, that's not how this would work. We would not touch the boot order at all. See https://github.com/rhboot/shim/pull/502 & https://mivehind.net/2022/08/17/shim-ab-booting-poc/. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F38 prospoal: Enable bootupd for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
> As we've talked about before, it's not possible to make updates > transactional. It involves, per spec and depending on processor > architecture, updating multiple files in different directories, > potentially on different filesystems entirely, one of which is fat32. I should probably have used only 'safe' here. My understanding of the "fallback work" was that with it, we could do updates automatically and retry them after failures without risking ending up in a state where we have no working bootloader. The update process would look like this: 1. Verify current bootloader hash 2. Fix it if not good 3. Copy current version to fallback 4. Update bootloader to new version What I've indeed forgotten to specify is that this only applies to EFI (so probably only x86 & aarch64) for now as that's what's implemented in bootupd. Am I missing something? > What's the plan to apply the outstanding security updates (shim, grub2, > and dbx push from June) to fedora silverblue 36 + 37 that aren't covered > by this change? We definitely want to backport all that to F36/37. This will only be possible for changes not in Anaconda, as we don't respin the installers. I'm not 100% sur yet we'll need Anaconda changes but mentioning it here in case it turns out we do. Thanks for the comments, I'll update the proposal. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: hardened memory allocate port to linux-fedora system for secutiry
I think that the first steps here would be to: - package it in Fedora - write a documentation page on how to use it (the quick docs may be a good place: https://docs.fedoraproject.org/en-US/quick-docs/) - do a lot of testing and benchmarks to get memory and performance numbers for each major Fedora use case (workstation, server, IoT, etc.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Re: F37 proposal: Linux Firmware Minimization (late System-Wide Change proposal)
Agree with Dusty here: it's likely that the DNF plugin won't be used at all with rpm-ostree. This change would however enable some rpm-ostree variants to more finely select the firmwares that they want: for example, Fedora CoreOS could skip all WiFi related firmwares and Fedora Silverblue could skip weird server hardware firmwares. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change Proposal: Unfiltered Flathub (System-Wide Change)
The two articles mentioned above all full of errors and misconceptions about how Flatpak and Flathub works. See https://theevilskeleton.gitlab.io/2022/05/16/response-to-flatpak-is-not-the-future.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 change proposal: Make Fedora CoreOS a Fedora Edition (System-Wide change)
We also probably need a new FESCO ticket. The current one still points to the one from the F34 change request: - https://fedoraproject.org/wiki/Changes/FedoraCoreOS - https://pagure.io/fesco/issue/2516 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
> I find this wording weird... I seriously doubt we should consider > "pkexec" legacy. It's the much nicer approach to the "sudo" > problem, > as mentioned in earlier discussions... > > Splitting it off into a separate package might be OK, but claiming > that the fact that it is a suid binary makes it "legacy" sounds really > strange to me, by that means we should also mark "sudo", "su", > "ping", > "mount", "umount", "write", "passwd", … and so on > "legacy", but I > doubt we are at that point, are we? > > hence I am not against the feature but please tone down the wording > regarding pkexec, it's misleading. Say you want to split it out to > reduce the attack surface, but don't use the word "legacy" in its > context. > > (dropping "pkla-compat" given its unmaintained state is Ok to be > called "legacy" i guess) I agree that the wording is stronger than it should be. I'll update that. -- Timothée Ravier CoreOS engineer & Fedora Kinoite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Make pkexec and pkla-compat optional (Self-Contained Change proposal)
> Splitting them off but making them Recommended seems odd to me. At that > point we've got all the work of splitting them but little of the > benefit, because soft dependencies are included when building images, > so our default installs are still going to include pkexec. > > Why not just not have them recommended at all, and instead try to find > all packages that use them and add dependencies, so that they will be > included when an image or whatever really does need them? Is that > considered too difficult? I went with Recommends to be conservative. We could indeed make them fully optional if we end up being confident we will not break the default user experience. -- Timothée Ravier CoreOS engineer & Fedora Kinoite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite (Self-Contained Change proposal)
> I use Silverblue. How does this affect my ability to modify /etc in the > opt-in scenario? Does rpm-ostree offer a method to modify /etc in that > case? What if I want a mutable /var, like I currently have, does this > change under this proposal? What is the value of this for the normal > Fedora Linux user? Note that this is only about `/sysroot`, not `/` (root). Thus `/etc` and `var` are still writable in all cases. > I don't know. I think not being able to boot into my previous > deployments a visible change to my user experience. Once the new option has been set, you will have to append `rw` to the kernel command line to previous deployments that were created before. We could also probably make this even more conservative and have it only enabled once all your deployments have the new kernel option. This should avoid the case where you can not bee an older deployment anymore. The idea is to make the update happen in two steps: - First add the `rw` kernel arguments, - Then set up the `sysroot.readonly` option once all previous deployments have the rw option. -- Timothée Ravier CoreOS engineer & Fedora Kinoite maintainer ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F36 Change: Podman 4.0 (Late Self-Contained Change)
Hi everyone, First of all, thanks a lot for all the work that went into podman v4. The release notes looks great and full of interesting changes! As I understand it, the podman client and server remote API are version locked: podman v3 clients can only speak with podman v3 servers, v4 clients with v4 servers. I think that this situation creates the need for a transition period between the two versions, where v3 & v4 are made available at the same time in Fedora 35 and 36. Users might be running podman on a variety of distributions as client (Fedora, etc.) and similarly as servers (Fedora CoreOS, Fedora Server, CentOS Stream, etc.). It is thus likely that they will need to be able to interact with podman v3 and v4 servers for some time until podman v4 is available everywhere. Having the podman v3 and v4 "client" packages available and co-installable in both Fedora 35 and 36 would help with the transition. For example, there could be a podman4 package in F35 and a podman3 package in F36. This would create an automatic upgrade path for the un-versioned podman package during the F35->36 upgrade for the local use case. Users would also be able to install the other podman version in case they needed to talk to a remote server. For Fedora CoreOS, providing co-installable "server" packages for podman v3 and v4 in Fedora 35 & 36 would enable us to ship both versions directly in the Fedora CoreOS image and thus create a nice transition period for users where they could select their preferred version on first boot. Note that I'm only advocating for co-installation, not co-usage of both podman v3 and v4. The "alternative" podman package would ship with renamed service units and binaries but everything else would be kept as is (only one TCP/UNIX socket for the service, etc.). This would also make it easier to test the new podman release and features by opting-in podman v4 on Fedora 35. Thanks, ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Self Introduction: Timothée Ravier (Siosm)
Hi everyone! I am Timothée Ravier and I am a Linux system and security engineer interested in safe programming languages and container focused operating systems. I am currently a Red Hat and Fedora CoreOS engineer. I maintain an unofficial project nicknamed Kinoite [1] that provide variants based on the KDE, XFCE, LXQt, Deepin, Mate and Pantheon desktop environments for Fedora Silverblue. To help Silverblue systems run applications in Flatpaks, I am working on packaging as many KDE applications as possible in Flatpaks for Flathub and hopefully in Fedora soon. I am working on translating the Fedora CoreOS, Silverblue and Flatpak docs in French. Regarding packaging, I am applying for co-maintainer-ship of the following packages: - https://src.fedoraproject.org/rpms/ostree - https://src.fedoraproject.org/rpms/rpm-ostree - https://src.fedoraproject.org/rpms/rust-bootupd - https://src.fedoraproject.org/rpms/rust-fedora-coreos-pinger - https://src.fedoraproject.org/rpms/rust-zincati Thanks! [1](https://discussion.fedoraproject.org/t/kinoite-a-kde-and-now-xfce-version-of-fedora-silverblue/147) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Kernel lockdown patch & IPAddressAllow/IPAddressDeny systemd feature with Secure Boot
Booting Fedora with Secure Boot enabled will result in Lockdown being enabled at boot time. This will completly disable the BPF system call for all users [1][2]. Unfortunately, this breaks the IPAddressAllow & IPAddressDeny systemd feature [3][4][5]. I don't have a solution for this, but as far as I understand, this will also prevent other BPF use-cases (for example: Cilium on Fedora CoreOS). [1] https://src.fedoraproject.org/rpms/kernel/blob/master/f/efi-lockdown.patch#_1525 [2] https://git.kernel.org/pub/scm/linux/kernel/git/jforbes/linux.git/commit/?h=lockdown=0eb0d0851747787f7182b3e9d0d38edb5925a678 [3] https://github.com/systemd/systemd/blob/master/src/core/bpf-firewall.c [4] https://github.com/systemd/systemd/blob/master/NEWS#L1192 [5] https://www.freedesktop.org/software/systemd/man/systemd.resource-control.html#IPAddressAllow=ADDRESS%5B/PREFIXLENGTH%5D%E2%80%A6 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ZMEWJMQH6DDMV3AZ4IG7LOYMMIETCH42/
Re: Dash as default shell
On 2014-10-02 10:25, Rahul Sundaram wrote: It doesn't even avoid Debian Ubuntu having a security problem, since they still need to fix bash. Sure. Unless they stop shipping bash, they got to fix security problems. That is no surprise. The real question is whether it reduced the impact of the issue for their users. What makes you think the dash doesn't have vulnerabilities too? Do note that I explicitly avoided making any such specific claims and instead proposed it as a discussion point for a good reason.Having said that, the general understanding appears to be that a minimal software with a smaller footprint has less potential issues. It's easy to forget that there have been much more serious vulnerabilities in dash than in bash as far as I can remember: http://blog.cmpxchg8b.com/2013/08/security-debianisms.html -- Timothée Ravier -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
