-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 BACKGROUND ============= On 2026-07-20, a 150MB binary file was committed to the ports tree, causing mirroring to GitHub and possibly other Git forges to fail due to a hard file size limit of 100MB. Additionally, it is unclear if the licensing of the binary permits redistribution in this fashion. On 2026-07-21, core@ became aware that mirroring was broken and requested the suspension of pushes to the ports repository while we assessed the situation. Discussions over the following hours among members of gitadm@, clusteradm@, portmgr@, and core@ resulted in a tentative plan to rewrite the repository history to remove the offending file, with the agreed constraint that the resulting state must be reproducible by third parties and must not impose an unreasonable burden on downstream consumers of the ports tree. The decision that the resulting state be reproducible by third parties arose from our shared view that we should not demand implicit trust, and that we should make it easy for our users and downstreams to reflect the same values. While `git rebase` can easily remove the offending commits, it imposes a greater audit burden on our community because it rewrites committer names and timestamps. It also affects the downstream communities which have forks of the ports tree. Providing a mechanism to repeat this operation has potential impact that extends far beyond our own community, and we appreciate your understanding and patience as we worked to get this right. ACTION REQUIRED ================= Commit hashes in `main` for commits after a70c5c3fd44b have changed as a result, which may impact your use of the ports tree. For all consumers of the ports tree, it is expected that the reproduction script linked below will correct the state of your repository to match the new state of the authoritative repository, but this is not the only option. For committers and contributors: pending pull requests and local branches will need to be rebased on top of the new history. For example: git rebase --onto f9c90a4f96f0700 0a717e9c118aa6 Where "0a717e9c118aa6" should be replaced with the _old_ upstream commit hash upon which your branch is based. Patch files should not be affected as the rewrite in question was isolated to the misc/github-copilot-cli port. For downstreams: running the reproduction script below is advised, particularly if you have local commits in your tree. The script will strip any cryptographic signatures on existing commits after the binary file commit to achieve reproducibility. Note that the script has two commit hashes embedded in it that will need to be changed if your branch has local changes included that may invalidate those; instructions for the replacement are included in the comments. TRANSPARENCY ============== The script used to rewrite commit history has been made available for independent verification and reproduction of the resulting state: https://www.freebsd.org/news/2026-ports-freeze/ports-reset.sh SHA256 (ports-reset.sh) = 9f954e7e229a1f3f0c452a98c433d70a0dbd265fc528bca6d082068d154536e8 This script should be run from within a checkout of the ports tree. Note that it does not attempt to purge the previous version of your branch entirely. Recovery by grabbing the previous commit hash from `git reflog` is possible if your local version of the branch does not have a remote to restore it from. Git garbage collection will eventually clean up the old branch in your repository. NEXT STEPS =========== Commit notes will be added both to the rewritten commits in main and to the commits in that range which were backported to 2026Q3, noting the old and new commit hashes in the least invasive way. We view the bar for rewriting a security update branch as significantly higher, and we have opted to accept that five commits will have incorrect commit messages referring to invalid cherry-pick commit hashes. Server-side hooks are being implemented in all three repositories to prevent future incidents of this particular nature. The exact shape hasn't been completely finalized, but the expectation is that there will be a hard upper file size limit with some lower soft limits that will require a --push-option or approval from portmgr/srcmgr/doceng. Separate hooks will be considered to confirm the licensing of binary artifacts being introduced into the repository. CONCLUSION =========== Huge thanks to everyone involved in incident response for all of the time put into ensuring that we perform this operation in a way that is auditable, reproducible, and with consideration for the massive impact both of the repository freeze and the impending rewrite. Rewriting commit history is not a decision that was made lightly, but it was agreed that taking the time to do this right was the least-bad option both for the project and for external ports trees that may have their own modifications following the commits in question. Special thanks to clusteradm@ for agreeing with the plan to rewrite history while staring at the long list of cluster infrastructure that will need to be fixed as a result. The ports tree will be thawed for regular operations in the coming hours, but infrastructure repairs will be conducted over the following week. Cluster package builds will not be restarted immediately, but will resume by 2026-07-26 at the latest. Signed, René Ladan (on behalf of portmgr@) Kyle Evans (on behalf of core@) A copy of this message is available independently for verification at: https://people.freebsd.org/~kevans/core/ports-freeze-final.txt.asc -----BEGIN PGP SIGNATURE----- iQJPBAEBCAA5FiEE3gJfirmYjuaWFv4NEBT7qDq7aZYFAmpjlXEbFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMiwzAAoJEBAU+6g6u2mWwTQQAIXO8QzaG5CfjJF9oSM8 1DNCUZFB59ifV9L7Bw9/Iakm1Iyy/YG/tkCUX+ZxePRkwrV567YsrFt3uAd4l8sR vJjm0JHkJK6PqnftO6+inz5w0vV+t1SILO/Rn3SHKBvVYzSHb4uLQARPONeR1lP/ y0i3Np79tf1YTlfSPLVYvF8cj+SRoRm4HWQvt+TmkWYAbxtJ6bfRaoScHDOXWVDd 3BShIA7BxS4VjZYZ+dh/D9FNIq1aUqkkqKBaNsMyDkdK1IiI0JHE+6U5lulQ5zDH 4kDFZYiY5RA8n9/1fHdIUMNMavnb0CG78XS8SA0MRm3bgK7tpA6j9h1bxzTnkkNc fPpi5tBwVtEmeY2jZRiZ7wyKP8DO5IqXTTu0uq7McF7jhYsHiHzthyYmUSicPzOE 0cbu6eHGq/OjalVaurg7R1CQ/8nsuJ0ICTHCMGlv71Ur2WzvNWmayTcd9Hy5LRu4 zatEQyrDLXk2QwtQ30k0Q6OI3tiscxQGDUG77d937pe7qYQPBjC5o0kZ4eYC8sMQ 4s0JFwnYuVruiLJZyfze4Y7yMGMcyW+DRxXkyPhCHh9B8s8ZUr9mdfvXywGkCnsl /eb8//5G7dWbxoN7E1/BCIulrp2rXi4kQMJDHmcvvix8u1qZfIj/ZAEgteyjENyC Co6NjrVjaupebUdc1GD0EgbV =wsye -----END PGP SIGNATURE-----
Friday, July 24, 2026
Thursday, July 23, 2026
[lfs-announce] Linux From Scratch Security Advisories
For some time we have been working on a new application to document security advisories for packages in LFS and BLFS. Originally we had been putting these into a simple list on the website. I would like to announce a new application that makes viewing and searching for security issues easier: https://www.linuxfromscratch.org/advisories/ These advisories are meant to provide information about the severity of issues that upstream developers have fixed and provide rationale for users to decide when to upgrade packages on their systems. As you may know, there have been an inordinate number of security issues that have been identified since LFS/BLFS 13.0 were published on March 5th. As of today we have 181 advisories in the system. More will be added as packages are added to the development versions of the books. I hope you find this new application useful. -- Bruce Dubbs linuxfromscratch.org
-- http://lists.linuxfromscratch.org/sympa/info/lfs-announce Unsubscribe: See the above information page
Wednesday, July 22, 2026
Ports Repository Freeze
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 You may have noticed that the ports repository has been frozen for nearly 24 hours now, at the time of writing. Our statement regarding the situation and next steps follows. A 150MB binary file was recently committed to the ports tree and, as a result, core@ made the decision to implement a temporary freeze of the ports tree in order to implement some clean up efforts. The commit in question severed our ports tree mirroring to github.com due to their filesize hard limit of 100MB, and introduced a blob of questionable licensing into the repository history. Given the importance of github.com mirroring to our community, we are actively taking steps to remove the offending commits and restore mirroring to the external services. There is no concern that the ports tree has been compromised. The freeze was entirely intended to limit the number of commits that will need to be re-written in order to issue a corrected state. It is important to us that we provide a reproducible and sustainable path for correcting this issue for the community and downstream consumers. As you're well-aware, correcting issues of this nature is not always as straightforward as desired. We are actively working on producing instructions which existing checkouts will need to follow to catch up with these corrections. To provide total transparency, we will also provide a procedure for verifying that the official repository changes enacted are limited to exactly the scope that we claim. We are also implementing server-side hooks to prevent this from happening in the future. Please stay tuned for additional updates from us, and thank you for your time. Thanks, Kyle Evans (on behalf of core@) -----BEGIN PGP SIGNATURE----- iJEEARYKADkWIQTOLDfUSTVFb0n/Wd5KG8EPLdVqEwUCamEskBsUgAAAAAAEAA5t YW51MiwyLjUrMS4xMiwyLDMACgkQShvBDy3VahPO5wEA+60GiOYCdejKOVJzCr5J fzuEQJxkWt/faQAsa9QlMI8BAMKuUIyRmCqFH99hcoPa4TgvABN3O99J9Mse5U/g chUI =QS8j -----END PGP SIGNATURE----- A copy of this message is available independently for verification at: https://people.freebsd.org/~kevans/core/ports-freeze-20260722.txt.asc
F46 Change Proposal: Changes Discussion Only On Devel List
Wiki - https://fedoraproject.org/wiki/Changes/ChangesDiscussionOnlyOnDevelList Discussion thread - https://discussion.fedoraproject.org/t/f46-change-proposal-changes-discussion-only-on-devel-list/197431 == Summary == Starting with Fedora Linux 46, discussion of Fedora Changes as part of the [https://docs.fedoraproject.org/en-US/operations/pgm%20guide/changes/ Changes Process] will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will continue to be announced on Discourse in read-only topics to provide a bridge between the two platforms. This Change aims to improve communication by avoiding having two separate mediums for the same discussion. == Owner == * Name: [[User:gotmax23| Maxwell G]], [[User:ngompa| Neal Gompa]], [[User:decathorpe| Fabio Valentini]], [[User:salimma | Michel Lind]] * Email: maxwell@gtmx.me, ngompa13@gmail.com, decathorpe@gmail.com, michel@michel-slm.name == Detailed Description == Starting with Fedora Linux 46, discussion of Fedora Changes as part of the [https://docs.fedoraproject.org/en-US/operations/pgm%20guide/changes/ Changes Process] will happen solely on the devel mailing list and will no longer be simultaneously discussed on Fedora Discussion (the Discourse forum). Changes will be announced on Discourse in read-only topics with links to the wiki page and devel discussion for each Change to provide a lightweight bridge between the two platforms. This Change aims to improve communication by avoiding having two separate mediums for the same discussion. The current "split brain" approach has been a significant pain point for Change Owners, FESCo members, and other project contributors attempting to follow Changes feedback discussion. Contributors have noted this as a cause of burnout. If technically feasible to use on read-only Discourse threads, we will keep the bot enabled that creates non-binding polls ("How do you feel about the proposal as written?") to collect community feedback on Changes. We will also adapt the bot to disable the anonymous results option on the Discourse polls so individual voices are better heard. FESCo will consider the polls alongside feedback on the devel list when voting on proposed Changes. == Feedback == There was some pre-Change discussion in "[https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/Q7KX3BDBUPCNOPVALP5GKR2MHTWB6ASD/ How can we improve the Changes Process?]" ([https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/VPQXOLZV3NVUOVTF4VCUEZU2BEFCQVQ5/ Maxwell's summary/takeaways]) on the devel list. This discussion was covered by LWN in [https://lwn.net/Articles/1081557/#:~:text=Changes%20to%20changes Fedora grapples with change § Changes to changes]. Additional feedback was provided in a [https://matrix.to/#/!DMptnKvPTdgoULzUTV:fedoraproject.org/$MuM8JzFoXojgU1x1LJMUO1Vn6kqOzTOjxSaLwqdjvdw?via=fedoraproject.org&via=fedora.im&via=matrix.org&web-instance%5Belement.io%5D%3Dchat.fedoraproject.org discussion in the #devel room on Matrix]. Feedback about Changes Discussion on Discourse was largely negative. Multiple contributors expressed that the current state of Changes discussion led to burnout. '''Q/A:''' * Why not just use Discourse for all Change Proposals and stop discussing them on the mailing list? ** The Change Owners do not wish to alienate or exclude existing contributors who rely on the mailing list workflow to participate in discussion. Other Fedora development discussion takes place on the devel mailing list, so it does not make sense to migrate only Changes discussion. Additionally, we believe that Discourse is an ill-suited platform for long, threaded discussions surrounding Fedora Changes. This position was discussed in more depth in the Matrix and devel list discussions linked above. * What about the email interface for Discourse? ** The email interface for Discourse is not comparable to a mailing list, and it de-prioritizes email users. The Discourse email support delays sending email notifications, makes formatting look out of place on responses sent via email, and email users miss out on reactions and other types of engagement. The ability to reply by email does not solve the issues with Discourse as a platform. == Benefit to Fedora == This Change aims to address a significant pain point in discussion of Fedora Changes. This should also simplify the Change Wrangler's work. == Scope == * Proposal owners: ** Update documentation and FESCo issue templates to clarify that the devel mailing list is the canonical medium for Changes discussion. ** Work with the Change Wrangler to implement the necessary process changes. * Other developers: ** Change wrangler: Announce Changes as usual on the devel-announce list. Stop copying and formatting Changes Proposal wikitext to/for Discourse. Create read-only posts on Discourse with links to the Wiki post and lists.fedoraproject.org discussion thread for each Change. ** Implement the proposed Changes to the Discourse voting poll creation bot. If these Changes are infeasible, disable the bot. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == == Early Testing (Optional) == == How To Test == == User Experience == Users, contributors, Change Owners, and FESCo members will all have one less place to follow for discussion about proposed Fedora Changes. Changes will continue to be announced on Fedora Discussion, and anyone currently subscribed via Discourse can follow links to the corresponding thread on lists.fedoraproject.org, which provides a lightweight web interface (Hyperkitty) to respond to list threads. Additionally, we will no longer post misformatted Change proposal texts on Fedora Discussion, instead providing a link to the canonical proposal on the Fedora Wiki. If technically feasible, the community feedback straw polls will remain enabled on Discourse. == Dependencies == == 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 == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
F46 Change Proposal: Deprecate low-memory-monitor package (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/DropLowMemoryMonitorFromDefaultInstallation Discussion thread - https://discussion.fedoraproject.org/t/f46-change-proposal-deprecate-low-memory-monitor-package-system-wide/197427 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 == Modern GLib (GMemoryMonitor) introduces memory monitor backends that run independently without relying on an external daemon to send low-memory signals to applications. Previously, low-memory-daemon was the sole provider of these events. Since GLib no longer requires low-memory-monitor to deliver these notifications and it is an archived project, low-memory-monitor can be deprecated. == Owner == * Name: [[smallorange| Kate Hsuan]] * Email: hpa@redhat.com == Detailed Description == With the introduction of native GMemoryMonitor backends [1-2] in GLib (including Linux kernel Pressure Stall Information (PSI) monitoring and a fallback polling mechanism), GLib can now monitor local memory usage directly. Previously, applications relied on an external background service, low-memory-monitor, via D-Bus to receive low-memory signals. The new Linux PSI backend actively monitors kernel-level resource pressure and emits signals to GMemoryMonitor subscribers when memory limits are reached. If PSI is disabled or unavailable, the fallback backend polls system memory metrics directly. Because GMemoryMonitor no longer requires a dedicated external daemon to function, low-memory-monitor can be deprecated. However, GLib retains the legacy D-Bus backend for low-memory-monitor to ensure backward compatibility with older distributions. [1] https://gitlab.gnome.org/GNOME/glib/-/merge_requests/4481 [2] https://systemd.io/PRESSURE/ == Feedback == See https://systemd.io/PRESSURE/ == Benefit to Fedora == Since GMemoryMonitor can run without an external service, low-memory-monitor can be deprecated. The runtime usage is reduced by stopping running low-memory-monitor. == Scope == * Proposal owners: Kate Hsuan * Other developers: * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == Glib2 manages all the dependencies and GMemoryMonitor runs independently, so upgrade/compatibility won't be impacted. == Early Testing (Optional) == == How To Test == 1. Make a test code from the example code mentioned in the documents [1].<br> 2. Compile and run the test program in a memory-limited system.<br> 3. Stree the memory until the signal is emitted.<br> [1] https://docs.gtk.org/gio/iface.MemoryMonitor.html == User Experience == == Dependencies == == 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) Bring back the low-memory-monitor package since the Dbus backend of GMemoryMonitor is still there. == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Web Based Remote Installation Support for Atomic Desktops (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Web_Based_Remote_Installation_Support_For_Atomic_Desktops Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-web-based-remote-installation-support-for-atomic-desktops-self-contained/197426 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 == Enable secure remote installation via the Anaconda WebUI on Fedora Atomic Desktop images. Users can boot a target machine with <code>inst.webui.remote</code> and complete the installation from a web browser on another machine over HTTPS with pin-based authentication. This change is scoped to Atomic Desktop images (Silverblue, Kinoite, etc.). == Owner == * Name: [[User:bciconelle| Bruno Ciconelle]] * Email: bciconel@redhat.com == Detailed Description == This change introduces remote installation as a '''tech preview''' for Fedora Atomic Desktop images. Users can boot with <code>inst.webui.remote</code> and complete the installation from a web browser on another machine — no VNC/RDP client needed. The Anaconda WebUI already supports remote access for development via <code>inst.webui.remote</code>, but without authentication, TLS, or configuration isolation. This change adds the production controls needed to ship it as an opt-in feature: * '''Pin-based authentication''' following the <code>inst.rdp</code> pattern, with an opt-out (<code>inst.webui.remote.noauth</code>) for development and trusted networks * '''HTTPS with self-signed certificates''' — cockpit generates these automatically * '''Port 443''' by default so users connect with just <code>https://<ip></code> * '''Isolated cockpit configuration''' under <code>/etc/anaconda/cockpit/</code> to prevent installer settings from leaking to the installed system Remote access is '''not enabled by default''' — it must be explicitly activated by the user via the <code>inst.webui.remote</code> boot option. Without it, behavior is completely unchanged. This change is scoped to Atomic Desktop images (see [[Changes/BuildAtomicDesktopsWithImageBuilder]]). == Feedback == The feature was [https://fedoramagazine.org/web-based-remote-installation-for-fedora-linux-heres-what-were-building/ announced on Fedora Magazine] in June 2026 with a developer preview and proof-of-concept. Community feedback included: * '''mDNS discovery''': Suggestion to advertise the installer via mDNS (e.g., <code>fedora-installer.local</code>) so users can find headless machines without knowing their DHCP-assigned IP. Not in scope for this initial MVP but noted as a valuable future improvement. * '''Tablet/phone support''': Cockpit's PatternFly widgets are responsive — storage configuration may be challenging on small screens but tablets should work well. * '''Lightweight boot ISO''': Interest in a minimal boot ISO without a local browser that defaults to remote installation — a headless/network-only variant. Not in scope for this change, but aligns with the broader [[Changes/ModernizeBootISO]] effort. == Benefit to Fedora == * '''New installation method''': Users can install Fedora Atomic Desktops from any device with a web browser — no VNC/RDP client software needed. This works from phones, tablets, Chromebooks, or any machine on the same network. * '''Better user experience than VNC/RDP''': The WebUI provides copy-paste support, a responsive layout, and runs in a standard web browser. No special client software to install or configure. * '''Secure by default''': Unlike VNC (historically unencrypted, 8-character password limit), remote installation uses HTTPS with TLS and user-set passwords. Authentication is required by default. * '''Practical graphical installation on lightweight ARM SBCs''': Devices like the Raspberry Pi have limited CPU and memory. Running a local browser consumes resources better used by the installer itself. With remote installation, the browser runs on the user's workstation and the target device only serves the lightweight cockpit-ws process. * '''Benefits any future boot.iso/netinst image that adopts the WebUI''': This change lives in <code>anaconda</code> and <code>anaconda-webui</code>, not in image-specific configuration. Any new boot.iso or network install image that migrates from the GTK interface to the WebUI — such as Fedora Server, which currently still uses GTK — will automatically gain remote installation support with no additional work. (Note: remote access on Live images is not supported.) * '''Community testing opportunity''': Landing in Fedora 45 Atomic images gives the community a full release cycle to test, report issues, and provide feedback before the feature is extended to other image types. == Scope == * Proposal owners: ** Modify <code>anaconda</code> to handle new boot options (<code>inst.webui.remote.password</code>, <code>inst.webui.remote.noauth</code>) in <code>argument_parsing.py</code> ** Update <code>CockpitUserInterface</code> and the cockpit startup flow to enable TLS, set port 443, and configure authentication based on boot options ** Modify <code>anaconda-webui</code>'s <code>cockpit-coproc-wrapper.sh</code> to conditionally remove <code>--no-tls</code> and change port when remote is active ** Generate cockpit configuration under <code>/etc/anaconda/cockpit/</code> at startup ** Implement password prompt on local console when password is missing (following <code>inst.rdp</code> pattern) ** All changes are within the <code>anaconda</code> and <code>anaconda-webui</code> packages * Other developers: N/A * Release engineering: N/A (no changes to image generation pipeline — images already include cockpit and anaconda-webui) * 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 aligns with the Fedora strategy of making Fedora easier to install and use, particularly for Atomic Desktops which are a focus area for Fedora's future. == Upgrade/compatibility impact == None. This change only affects the installation environment. No configuration or data is carried to the installed system. Users who do not use <code>inst.webui.remote</code> see no change whatsoever. == How To Test == # Boot a Fedora 45 Atomic Desktop ISO (Silverblue, Kinoite, or similar) # At the boot menu, add kernel options: <code>inst.webui.remote inst.webui.remote.password=testpin</code> # The installer will display the machine's IP address on the local console # From another machine on the same network, open a browser and navigate to <code>https://<ip></code> # Accept the self-signed certificate warning in the browser # Enter <code>testpin</code> at the login prompt # The Anaconda WebUI should load and allow you to proceed with the installation # Test tab close (should reconnect without re-login) and browser close (should require re-login) '''Additional test cases:''' * Boot with <code>inst.webui.remote</code> only (no password) — installer should prompt for a password * Boot with <code>inst.webui.remote inst.webui.remote.noauth</code> — remote access should work without authentication * Boot without <code>inst.webui.remote</code> — remote access should NOT be available (current default behavior preserved) == User Experience == See the [https://fedoramagazine.org/web-based-remote-installation-for-fedora-linux-heres-what-were-building/ Fedora Magazine article] for a detailed overview of the remote installation experience and the ''How To Test'' section above for step-by-step instructions. Users who do not use <code>inst.webui.remote</code> will see no change in their experience. == Dependencies == The [https://github.com/rhinstaller/anaconda-webui anaconda-webui] package is maintained by the installer team and has a dependency on [https://cockpit-project.org/ Cockpit]. There are no unfinished work items blocking this initiative. == Contingency Plan == * Contingency mechanism: No action needed. The feature is opt-in and in tech preview — it is only activated when the user explicitly passes <code>inst.webui.remote</code> on the kernel command line. Without this boot option, the installer behaves identically to previous releases. An incomplete or buggy implementation does not affect normal installation workflows. N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? No. The feature is opt-in. If incomplete, remote installation remains in its current development-only state. Local installation and all other installation methods are completely unaffected. == Documentation == * [https://redhat.atlassian.net/browse/INSTALLER-3723 INSTALLER-3723] — Epic tracking all remote installation work == Release Notes == Fedora 45 introduces secure remote installation support for Atomic Desktop images (Silverblue, Kinoite, and others). You can now install Fedora from a web browser on another device by adding <code>inst.webui.remote inst.webui.remote.password=YOURPIN</code> to the kernel boot options. The installer uses HTTPS with a self-signed certificate and listens on port 443, so you can connect by navigating to <code>https://<ip></code> from any web browser. This feature is opt-in and in tech preview — installations without <code>inst.webui.remote</code> are unaffected. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: IBus 1.5.35 (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/IBus_1.5.35 Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-ibus-1-5-35-self-contained/197425 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 == IBus 1.5.35 will enhance the handling of XKB keymaps in Wayland desktop environments == Owner == * Name: [[User:Fujiwara|Takao Fujiwara]] * Email: fujiwara [at] redhat [dot] com == Detailed Description == * IBus now supports the ISO latch and shift states of XKB keymaps in Wayland desktop environments likes KDE, Sway, Hyprland, COSMIC. * IBus now supports the IBus option to use the session keymaps regardless of the keymap of each input method engine. == Feedback == https://bugzilla.redhat.com/show_bug.cgi?id=2444009 == Benefit to Fedora == This change will enhance the usability in the Wayland desktop enviroments with the Wayland input-method protocols when user enables IBus input method framework for some XKB keymaps like "lv(tilde)", "de(T3)", "fr(ergol)". == Scope == * Proposal owners:ibus 1.5.35 * Other developers: * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == == Early Testing (Optional) == == How To Test == === XKB keymap === # Configure `"us"` keymap in the system keymap with the `localectl` command and `/etc/vconsole.conf` file # Log into the Wayland desktop environment with the Wayland input-method protocol like KDE, Sway, Hyprland, COSMIC # Run `ibus start` to enable IBus and configure each DE with https://github.com/ibus/ibus/wiki/WaylandDesktop # Run `ibus-setup` utility and configure some XKB keymaps like `"Latvian (tilde)"` and enable one with {{key press|Super|space}} shortcut key # Type some ISO latch keys like {{key press|tilde|e}} or {{key press|AltGr|e}} The IBus XKB keymaps work fine and the system keymap is supported with `"us"` or the same keymap of the IBus keymap. === System keymap option === # Configure `"us"` keymap in the system keymap with the `localectl` command and `/etc/vconsole.conf` file # Log into the Wayland desktop environment with the Wayland input-method protocol like KDE, Sway, Hyprland, COSMIC. # Run `ibus start` to enable IBus and configure each DE with https://github.com/ibus/ibus/wiki/WaylandDesktop # Run `ibus-setup` utility and enable `"Use system keyboard layout"` option # Run `ibus-setup` utility and configure some XKB keymaps or input-method engines and enable one with {{key press|Super|space}} shortcut key Expected result is all keys are based on `"us"` keymap. == User Experience == IBus works with the XKB keymaps with the `ibus-setup` utility whether each DE supports the ISO latch keys or not. == Dependencies == IBus panel needs the waybar in Sway desktop environment since the default swaybar does not support StatusNotifier. == Contingency Plan == * Contingency mechanism: Revert the change to ibus. * Contingency deadline: Beta release * Blocks release? No == Documentation == TBD == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Encapsule isolated devel containers (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Encapsule_devel_containers Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-encapsule-isolated-devel-containers-self-contained/197423 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 == [https://github.com/juhp/encapsule encapsule] is a new small CLI tool for developers who want to try out "tools installed from the internet" for example (or use them within a project workdir) inside a safer container environment rather than directly in their home directory and host system. == Owner == * Name: [[User:Petersen|Jens Petersen]] * Email: <petersen@redhat.com> == Detailed Description == The CLI tool allows running developer containers, isolating your home directory and host from container side effects: it can "encapsule" a project and/or temp homedir there together with select enabled "capabilities". It uses Podman to run a (derived) container image (which can be generated by Buildah from a toolbox container say). The project [https://github.com/juhp/encapsule#readme readme] file has more details about the specific features and commandline options. In this age developers are frequently asked to install and run all kind of commands or software directly from the internet whether from source or more often now binaries. In recent years `curl https://some.project/install.sh | bash` or `npm/npx install ...` (and many others: pip, cargo, etc) are being normalized and can both pollute one's home directory or system, and also put it at increased security risk. `encapsule` provides a lightweight, somewhat safer environment for installing and running such tools. Note however it is ''not'' intended for running known malicious programs or security testing, etc - though at least it provides some basic separation or system hygiene. Users can also disable sudo or even the network (or potentially DNS) inside the encapsule container. In many ways it makes opposite design choices to toolbox: closed by default rather than open - but one can opt in to sharing specific things from the host. A lot of the original ideas are derived from [https://github.com/swick/toolbox-constrained/ toolbox-constrained] by Sebastian Wick, without which this tool probably wouldn't exist now in its current form. For more hardened isolation it is recommended to look at OpenShell though it is not available yet in Fedora. In the future it may be possible to migrate `encapsule` to wrap `openshell` for instance and use its gateway perhaps, which would enhance network isolation considerably. The alternative is to use a VM of course, but that is much more heavyweight and awkward: though there is the similar [https://github.com/whot/schupfn whot/schupfn] project, which allows exporting specified directories with 9p to a QEMU VM instance, also generated from a toolbox. == Feedback == == Benefit to Fedora == Fedora users will have a simple way to isolate toolbox containers etc from their homedir and host system for running third party tools inside a contained environment, where they control what is shared from their home or host system. == Scope == * Proposal owners: ** Submit `encapsule` for package review and get it approved ** Fix reported issues and improve further * Other developers: N/A * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == Upgrade/compatibility impact == N/A == Early Testing (Optional) == https://copr.fedorainfracloud.org/coprs/petersen/encapsule/ == How To Test == * `sudo dnf install encapsule` * `encapsule --help` * `encapsule fedora-toolbox:44 -p myproject` * `encapsule fedora-toolbox-44 --home tmphome` * https://github.com/juhp/encapsule#examples == User Experience == Users will have a safer way to run harnesses and other tools grabbed from the internet. == Dependencies == == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change) * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) == Documentation == N/A (not a System Wide Change) == Release Notes == To be written -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Disable in Kernel Crypto Userspace API (Phase 1) (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Disable_CRYPTO_USER_API Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-disable-in-kernel-crypto-userspace-api-phase-1-self-contained/197422 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 in kernel Crypto Userspace API (CRYPTO_USER_API) is now deprecated upstream, with some parts of it being actively removed early in the 7.2 cycle, because of the security risk it contains. It is due to be disabled and actively removed from upstream in the near future. Restrict it's use in Fedora to known active users early so we can do a controlled ending of support and can make the community aware of it's pending disappearance and gracefully deal with unknown users. == Owner == * Name: [[User:pbrobinson| Peter Robinson]], [[User:jforbes| Justin Forbes]] * Email: [mailto:pbrobinson@fedoraproject.org pbrobinson@fedoraproject.org], [mailto:jforbes@fedoraproject.org jforbes@fedoraproject.org] == Detailed Description == The in kernel Crypto Userspace API (CRYPTO_USER_API) is now deprecated upstream, with some parts of it being actively removed early in the 7.2 cycle, because of the security risk it contains. It is due to be disabled and actively removed from upstream in the near future. The first phase will restrict it's use in Fedora early so we can do a controlled ending of support and can make the community aware of it's pending disappearance and gracefully deal with unknown users. There's not a lot of known users of the in kernel Crypto Userspace API so the impact should be minimal and there's upstream planning for most of those. The known Fedora users of the Crypto Userspace API are iwd, cryptsetup (just used for [https://www.man7.org/linux/man-pages/man8/cryptsetup.8.html#TCRYPT_(TRUECRYPT_AND_VERACRYPT_COMPATIBLE)_EXTENSION TrueCrypt, tcplay, or VeraCrypt] and some kernel level benchmarking) and libkcapi (used by dracut, kernel build process). These users are unaffected by this phase of the change. The cryptsetup already has the ability to fall back to other mechanisms. The iwd users will continue to function but users likely should migrate to wpa_supplicant (the iwd package is currently unmaintained upstream). The first phase uses the upstream patches due to land shortly, likely in 7.3, to limit the use of the API to the known apps and restricts the use. This allows Fedora to identify unknown users and gracefully deal with them before the active demise of the interface upstream providing users a more graceful process rather than universally pulling the rug without any notice. == Benefit to Fedora == The benefit to Fedora is to allow users of the in kernel crypto API to be aware of the impending disappearance of the interface and to give them some time to gracefully migrate to other userspace interfaces before the API is gone for good. == Scope == * Proposal owners: ** Ensure all the components that use the crypto userspace APIs have migrated to other userspace crypto APIs. ** Document the the replacements * Other developers: ** No impact * Release engineering: [https://pagure.io/releng/issue/XXXX #XXXX] ** [[Fedora_Program_Management/ReleaseBlocking/Fedora{{FedoraVersionNumber|next}}|List of deliverables]]: N/A (not a System Wide Change) * Policies and guidelines: N/A (not a System Wide Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == No current known users of the crypto userspace kAPIs are affected and will continue to work. There may be third party users which will be identified as part of this process to allow us to work with them to mitigate/migrate to more suitable interfaces. == How To Test == * Install a Fedora 7.2 kernel build == User Experience == Generally users should not notice. The kernel Crypto Userspace API was never widely used and the in Fedora packages that make use of it will migrate to other mechanisms without users being aware of the change. == Dependencies == No external dependencies. == Contingency Plan == * Contingency mechanism: Re-enable * Contingency deadline: GA * Blocks release? No. * Blocks product? No. == Documentation == There's no specific kernel Crypto Userspace API documentation in Fedora. == Release Notes == Fedora has actively deprecated the in kernel Crypto Userspace API and no longer actively supports it's use. If you currently use the userspace crypto API please migrate to another suitable userspace crypto API. -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
F45 Change Proposal: Anaconda WebUI Fedora Atomic (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Anaconda_WebUI_Fedora_Atomic Discussion thread - https://discussion.fedoraproject.org/t/f45-change-proposal-anaconda-webui-fedora-atomic-self-contained/197421 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 == Switch the installer used by Fedora Atomic ISO images from the legacy GTK-based Anaconda installer to the new WebUI installer. This aligns the installation experience of Atomic media with Fedora Workstation, KDE and Fedora Live Spins. == Owner == * Name: [[User:Kkoukiou | Katerina Koukiou]] * Email: kkoukiou@gmail.com * Name: [[User: supakeen | Simon De Vlieger]] * Email:''' [mailto:cmdr@supakeen.com cmdr at supakeen.com] or [mailto:supakeen@redhat.com supakeen at redhat.com] or [mailto:supakeen@fedoraproject.org supakeen at fedoraproject.org] * Name: [[ User:Siosm | Timothee Ravier ]] * Email: siosm@fedoraproject.org == Detailed Description == The Anaconda WebUI is becoming the standard installer experience across Fedora. This proposal extends that transition to Fedora Atomic installer ISOs, providing a consistent installation experience with current Live installations. Affected installer ISOs: * Fedora Silverblue * Fedora Kinoite * Fedora COSMIC Atomic * Fedora Sway Atomic (Sericea) * Fedora Budgie Atomic (Onyx) == Feedback == == Benefit to Fedora == Reduces maintenance by using a single installer implementation. See also the Change proposal from [https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation#Benefit_to_Fedora WebUI adoption to Workstation]. == Scope == * Proposal owners: - Switch Fedora Atomic installer ISOs to use the Anaconda WebUI. - Complete validation and testing across all affected Atomic variants. * Other developers: * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues #Releng issue number] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: == How To Test == Once the anaconda-webui package is required by `anaconda` main package [1] the affected Rawhide Atomic ISOs can be used for testing. [1]https://github.com/rhinstaller/anaconda/pull/7170 == User Experience == See [https://fedoraproject.org/wiki/Changes/AnacondaWebUIforFedoraWorkstation#User_Experience Change proposal for WebUI adoption] from different Fedora variants. == Dependencies == The [https://src.fedoraproject.org/rpms/anaconda-webui package] for WebUI installer is maintained by the installer team and has dependency on [https://src.fedoraproject.org/rpms/cockpit Cockpit]. There are not unfinished work items blocking this initiative. == Contingency Plan == * Contingency mechanism: If significant issues are identified before the release, Fedora Atomic installer ISOs will revert to using the GTK-based Anaconda installer * Contingency deadline: We have the contingency plan ready * Blocks release? No. We can revert the change easily if blockers show up == Documentation == N/A (not a System Wide Change) == Release Notes == -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Tuesday, July 21, 2026
REMINDER: F45 Self-Contained Change Proposal Submission Closes Today
Hi all, Reminder: You must submit your F45 self-contained change proposal today[1] to be considered for this next release. The Changes template and isntrcutions can be found at the top of this page[2]. If you miss this deadline, please consider proposing your change for F46 instead[3]. [1] https://fedorapeople.org/groups/schedule/f-45/f-45-key-tasks.html [2] https://docs.fedoraproject.org/en-US/operations/changes_policy/ [3] https://fedorapeople.org/groups/schedule/f-46/f-46-key-tasks.html Kind regards, Aoife -- Aoife Moloney Fedora Operations Architect Fedora Project Matrix: @amoloney:fedora.im IRC: amoloney -- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new
Monday, July 20, 2026
Fedora 45 Mass Rebuild Completed
As per the Fedora 45 release schedule [1], we started a mass rebuild for Fedora 45 on 2026-07-15. This is now completed.
The mass rebuild was run for the changes listed here:
https://fedoraproject.org/wiki/Fedora_45_Mass_Rebuild#Driving_Changes
The rebuild was done in a side tag (`f45-rebuild`) that was merged into the release tag (`f45`).
Failures from the mass rebuild can be found here:
https://kojipkgs.fedoraproject.org/mass-rebuild/f45-failures.html
Packages that still need to be rebuilt can be found here:
https://kojipkgs.fedoraproject.org/mass-rebuild/f45-need-rebuild.html
FTBFS bugs will be filed shortly for the remaining failures.
Discussions related to the Fedora 45 mass rebuild took place in the tracker ticket [2].
Please let Release Engineering know if you notice any issues with the reporting.
You can contact us through the Release Engineering Matrix room [3] or by opening a ticket on our issue tracker [4].
Patrik Polakovic
Fedora Release Engineering
[1] https://fedorapeople.org/groups/schedule/f-45/f-45-all-tasks.html
[2] https://forge.fedoraproject.org/releng/tickets/issues/13406
[3] https://matrix.to/#/#releng:fedoraproject.org
[4] https://forge.fedoraproject.org/releng/tickets/issues
-- _______________________________________________ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave@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-announce@lists.fedoraproject.org Do not reply to spam, report it: https://forge.fedoraproject.org/infra/tickets/issues/new