Thursday, October 29, 2026

Fedora Linux 45 Final is GO

The Fedora Linux 45 Final RC 1.4 compose is GO and will be shipped live on Tuesday, 3 November 2026. For more information please check the Go/No-Go meeting minutes[1] or log[2], and our schedule[3]. Thank you everyone for contributing to another great Fedora Linux release! Kindest regards, Aoife [1] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-29/f45-final-go-no-go-meeting.2026-10-29-18.02.html [2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-29/f45-final-go-no-go-meeting.2026-10-29-18.02.log.html [3] https://fedorapeople.org/groups/schedule/f-45/f-45-key-tasks.html -- 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

Wednesday, October 28, 2026

F46 Change Proposal: Usermode2 (self-contained)

Wiki - https://fedoraproject.org/wiki/Changes/Usermode2 Discourse poll - https://discussion.fedoraproject.org/t/f46-change-proposal-usermode2-self-contained/206311/2 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 == Replace the C implementation of the `usermode` package with a Rust rewrite of its `userhelper`/`consolehelper` tools. For those two tools, the rewrite is a drop-in replacement: same package name, same setuid-root/unprivileged binary split, same `/etc/pam.d` and `/etc/security/console.apps` configuration format, and the same command-line interface. The package's other, obsolete tools, `usermount`, `consolehelper-gtk`, `userpasswd`, `userinfo`, and `pam-panel-icon`, are dropped and not reimplemented. == Owner == * Name: [[User:asn| Andreas Schneider]] * Email: asn@redhat.com == Detailed Description == `userhelper` is a setuid-root helper that authenticates a user via PAM and runs a privileged program on their behalf. `consolehelper` is its unprivileged wrapper, prompting the user at the console or via a graphical `pinentry` dialog on `userhelper`'s behalf. Together they let an administrator grant ordinary users PAM-gated access to a specific privileged program, without making that program itself setuid. The existing C implementation (last released as usermode 1.114) has had no upstream release since 2014. This Change replaces it with a rewrite in Rust, a memory-safe language, while keeping the package name, on-disk configuration format, and CLI of `userhelper`/`consolehelper` unchanged so existing `console.apps`/PAM configurations for managed programs keep working without modification. The original `usermode` package also shipped several standalone GUI tools, all obsolete and all dropped from the rewrite: * `usermount`, for mounting/unmounting removable media, superseded by `udisks`/`polkit` and modern desktop auto-mount handling. * `consolehelper-gtk`, a separate `consolehelper` variant linked against GTK2 (long end-of-life), unnecessary since `consolehelper` drives `pinentry` for its GUI prompts rather than linking a GTK toolkit directly, so there is no separate toolkit-specific binary to maintain. * `userpasswd`, a GUI password-change dialog, superseded by `passwd(1)` and the account-settings password dialogs built into modern desktop environments. * `userinfo`, a GUI equivalent of `chfn`, superseded by `chfn(1)` and modern `accountsservice`-based desktop account-settings panels. * `pam-panel-icon`, a notification-area icon for `pam_timestamp` status, whose use has declined along with `pam_timestamp` itself. None of these are reimplemented in the rewrite. The privilege-separated design is preserved and sharpened: the only setuid-root binary is `userhelper`, kept to PAM calls, privilege transitions, and `exec`. GUI/toolkit code and the `pinentry` dependency live entirely in the unprivileged `consolehelper`, which relays PAM conversation requests to `userhelper` over a socket rather than `userhelper` linking GUI code directly. Secrets (passwords, PAM authtoks) are held in `memsecurity`-backed zeroizing memory for their entire lifetime in both processes, rather than plain `String`/`Vec<u8>`. * Source: https://gitlab.com/cryptomilk/usermode * Design: https://gitlab.com/cryptomilk/usermode/-/blob/main/DESIGN.md == Feedback == No feedback collected yet; this proposal has not been publicly announced. == Benefit to Fedora == `userhelper` is one of the few setuid-root binaries shipped in Fedora, making memory-safety bugs in it directly security relevant. The rewrite removes the memory-unsafety risk (buffer overflows, use-after-free, uninitialized reads) inherent to the original C implementation, which has had no upstream release since 2014 and no active upstream maintenance. Functionality for `userhelper`/`consolehelper` is unchanged for administrators and users: the same binaries, the same `console.apps`/PAM configuration keys (`USER`, `UGROUPS`, `SESSION`, `FALLBACK`, `RETRY`, `GUI`, `NOXOPTION`, `BANNER`, `KEEP_ENV_VARS`, config-file includes, ...), and the same exit codes and man pages. Existing packages that integrate with `consolehelper` (e.g. via a symlink to a managed program name) require no changes. One notable consumer is the `mock` package, which ships `/etc/security/console.apps/mock` and `/etc/pam.d/mock` so users in the `mock` group can run it without full root privileges. The package also drops five long-obsolete tools (`usermount`, `consolehelper-gtk`, `userpasswd`, `userinfo`, `pam-panel-icon`), trimming the setuid-root attack surface and packaging maintenance burden to the two tools that are still actively used. This aligns with Fedora's broader push to adopt memory-safe languages for security-critical system components. == Scope == * Proposal owners: Add missing Rust dependencies to Fedora (rust-ascon-aead, rust-ascon-core, rust-bitcode, rust-bitcode_derive, rust-memsec, rust-memsecurity, rust-pam-client2, rust-pam-sys2, rust-pinentry, rust-random-detached). Update the Fedora `usermode` package to build and ship the Rust rewrite. Packages are already available for test installation via COPR: https://copr.fedorainfracloud.org/coprs/asn/usermode/ * Other developers: N/A (not a System Wide Change) * Release engineering: N/A (not a System Wide Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: Yes: this is a memory-safety improvement to a security-sensitive, privileged system component, in line with Fedora's ongoing effort to reduce memory-unsafe code in security-critical paths. == Upgrade/compatibility impact == For `userhelper`/`consolehelper`: none expected. The package name, binary names, file locations and modes (`userhelper` setuid root, `consolehelper` 0755), configuration file format (`/etc/security/console.apps/<prog>`, `/etc/pam.d/<prog>`), and command-line interface are unchanged from the C implementation. Existing managed-program configurations continue to work unmodified across the upgrade. `usermount`, `consolehelper-gtk`, `userpasswd`, `userinfo`, and `pam-panel-icon` are removed from the package. Systems still invoking any of these directly, symlinking `consolehelper` to `usermount` or `userpasswd`/`userinfo`, or relying on `consolehelper-gtk` specifically rather than `consolehelper`, lose that functionality on upgrade. This is expected to affect few if any systems given these tools' functionality has been superseded for years. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == 1. No special hardware is needed. A test VM or container is recommended since `userhelper` is setuid root. 2. Install the rewrite from COPR: https://copr.fedorainfracloud.org/coprs/asn/usermode/ (or build from source per the project README: https://gitlab.com/cryptomilk/usermode). 3. Create a PAM service file at `/etc/pam.d/<prog>` and a config file at `/etc/security/console.apps/<prog>` for a test program, e.g.: <pre> # /etc/security/console.apps/testprog USER=root PROGRAM=/usr/bin/id </pre> 4. Symlink `consolehelper` under the managed program's name (`ln -s /usr/bin/consolehelper /usr/bin/testprog`) and run it as an unprivileged user, both at a graphical session (verifying the `pinentry` prompt) and from a plain console/SSH session (verifying the text PAM conversation). 5. Expected result: after successful authentication per the PAM service's policy, the wrapped program (`/usr/bin/id` in the example) runs with root privileges and its output is shown to the user; failed authentication is rejected with the documented exit code and no privileged program runs. == User Experience == No visible change for end users or administrators. `userhelper` and `consolehelper` behave the same as the C implementation: the same authentication prompts (graphical `pinentry` or console), the same configuration options, and the same error messages/exit codes. == Dependencies == Build-time dependency on a Rust toolchain (`rustc`/`cargo`) and the Rust crates in `Cargo.lock` (notably `pam-client2`, `nix`, `memsecurity`, `zeroize`, `pinentry`, `log`, `thiserror`, `serde`/`serde_json`), all already packaged in Fedora or vendored per standard Rust packaging guidelines. At runtime, `userhelper` depends on `pam` for authentication, same as the C implementation. `consolehelper` depends on `pinentry` for its graphical password prompt. Both are already Fedora packages. No other Fedora packages depend on `usermode` for their build. At runtime, packages such as `mock` depend on `consolehelper` through the symlink convention described above; this rewrite keeps that runtime interface unchanged. == Contingency Plan == * Contingency mechanism: Revert the `usermode` package to the last C implementation build. (Andreas Schneider) * Contingency deadline: Beta freeze. * Blocks release? No. == Documentation == Upstream README, DESIGN.md, and `userhelper(8)`/`consolehelper(8)` man pages: https://gitlab.com/cryptomilk/usermode == Release Notes == `usermode` (`userhelper`/`consolehelper`) is now implemented in Rust instead of C, improving memory safety for this setuid-root component. No configuration or behavior changes are expected; existing `console.apps`/PAM configurations continue to work unchanged. -- 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: TzdataZicSlimFormat (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/TzdataZicSlimFormat Discourse Poll - https://discussion.fedoraproject.org/t/f46-change-proposal-tzdatazicslimformat-system-wide/206308 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 == tzdata will use the default ‘slim’ data format for generating zoneinfo files rather than the previous 'fat’ data format. == Owner == * Name: [[User:pfrankli| Patsy Griffin]] * Email: pfrankli@redhat.com == Detailed Description == In 2019, the upstream tzdata project added the -b option to zic. The -b option supports a way to control data bloat and to test for year-2038 bugs in software that reads TZif files. 'zic -b fat' generates the traditional larger output files. 'zic -b slim' generates smaller output. In Fedora, tzdata currently uses the 'zic -b fat' format to generate zoneinfo files for compatibility with older software. The 'fat' and 'slim' files represent the same set of timestamps and use the same TZif format as documented in tzfile(5). The fat format tries to work around bugs or incompatibilities in older software. Specifically, software that mishandles 64-bit TZif data or uses obsolete TZ strings like EET-2EEST that lack DST rules. Slim format is more efficient and does not work around 64-bit bugs or obsolete TZ strings. Since 2020, the upstream project has been generating 'slim' format by default. This change request proposes transitioning to the default 'slim' format to reduce file size and provide advance warning of 2038 bugs in software that reads TZif files. == Feedback == I discussed this change with libstdc++. They do not think this change will impact them. Similarly, Java does not use the binary files and therefore does not expect to be impacted. I discussed this change with the pytz package maintainer. They observed some test failures but felt they could be handled with some code changes. == Benefit to Fedora == Use of zic's default slim file format will control data bloat and reduce zoneinfo file sizes. == Scope == * Proposal owners: This is a simple change for tzdata. We simply need to remove the command line option that forces zic to use the fat data format. * Other developers: Currently, we are aware that pytz may need some code changes. Having discussed this with the package owner, it is assumed to be a small amount of work. We don't know if other packages will be impacted. * Release engineering: No release engineering changes are required. * 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 == No upgrade compatibility impact expected. == Early Testing (Optional) == Do you require 'QA Blueprint' support? N == How To Test == Create two copies of the zoneinfo using both zic -b fat and the default zic output. Use zdump to dump some zones from each version of zoneino, America/New_York for example. Compare the zone information for each version. The time zone information should be the same. NOTE: The 'fat' format may contain some extraneous information. == User Experience == Data files created by zic will now be considerably smaller. == Dependencies == == Contingency Plan == * Contingency mechanism: If this change results in unforeseen issues we can remove the proposal and leave tzdata as is until the unforeseen issues are resolved. * Contingency deadline: Beta freeze * Blocks release? This change should not block the release. == Documentation == The upstream tzdata NEWS file contains several entries relating to the zic 'slim' and 'fat' formats. == 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

F47 Change Proposal: Python 3.16 (system-wide)

Wiki - https://fedoraproject.org/wiki/Changes/Python3.16 Discourse Poll - https://discussion.fedoraproject.org/t/f47-change-proposal-python-3-16-system-wide/206307/2 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 == Update the Python stack in Fedora from Python 3.15 to Python 3.16, the newest major release of the Python programming language. == Owner == * Name: [[User:ksurma| Karolina Surma]] * Name: [[User:churchyard| Miro HronĨok]] * Email: python-maint@redhat.com == Detailed Description == We would like to upgrade Python to 3.16 in Fedora 47 thus we are proposing this plan early. See the upstream notes at [https://docs.python.org/dev/whatsnew/3.16.html What's new in 3.16]. === Important dates and plan === * 2026-05-07: Python 3.16 development begins * 2026-10-13: Python 3.16.0 alpha 1 ** Package it as {{package|python3.16}} for testing purposes ** Start the bootstrap procedure in Copr ** Do a mass rebuild against every future release in Copr * 2026-11-10: Python 3.16.0 alpha 2 * 2026-12-15: Python 3.16.0 alpha 3 * 2027-01-12: Python 3.16.0 alpha 4 * 2027-02-09: Python 3.16.0 alpha 5 * 2027-02-09: Branch Fedora 46, Rawhide becomes future Fedora 47 ** The earliest point when we can start rebuilding in Koji side-tag * 2027-03-09: Python 3.16.0 alpha 6 * 2027-04-13: Python 3.16.0 alpha 7 * 2027-05-04: Python 3.16.0 beta 1 ** No new features beyond this point * 2027-05-25: Python 3.16.0 beta 2 ** The ideal point when we can start rebuilding in Koji * 2027-06-01: Expected side tag-merge (optimistic) * 2027-06-15: Python 3.16.0 beta 3 * 2027-06-15: Expected side tag-merge (realistic) * 2027-06-29: Expected side tag-merge (pessimistic) * 2027-07-13: Python 3.16.0 beta 4 * 2027-07-21: Fedora 45 Mass Rebuild ** The mass rebuild happens with the fourth or third beta. We might need to rebuild Python packages later in exceptional case. ** If the Koji side-tag is not merged yet at this point, we defer the change to Fedora 48. * 2027-07-27: Python 3.16.0 candidate 1 ** This serves as "final" for our purposes. * 2027-08-10: Branch Fedora 47, Rawhide becomes future Fedora 48 * 2027-08-10: Fedora 47 Change Checkpoint: Completion deadline (testable) * 2027-08-24: Fedora Beta Freeze ** If rebuild with 3.16.0rc1 is needed, we should strive to do it before the freeze - there is a window of 4 weeks. * 2027-08-31: Python 3.16.0 candidate 2 * 2027-09-14: Fedora 47 Beta Release (Preferred Target) ** Beta will likely be released with 3.16.0rc2. * 2027-10-05: Python 3.16.0 final * 2027-10-05: Fedora 47 Final Freeze ** If the 3.16.0 final release is delayed, we'll update it using a freeze exception. * 2027-10-19: Fedora 47 Final Target date #1 * 2027-10-26: Fedora 47 Final Target date #2 (From [https://peps.python.org/pep-0826/#release-schedule Python 3.16 Release Schedule] and [https://fedorapeople.org/groups/schedule/f-47/f-47-key-tasks.html Fedora 47 Release Schedule].) The schedule might appear somewhat tight for Fedora 47, but Python's [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/AKA3USBKFYKUQDSGDK4FNDYYWMKM7XKX/ annual release cycle was adapted for Fedora] and this worked fine since Python 3.9 and Fedora 33. It is now common that Python is upgraded on a similar schedule in every odd-numbered Fedora release. Note that upstream's "release candidates" are frozen except for blocker bugs. Since we can and will backport blocker fixes between Fedora and upstream, we essentially treat the Release Candidate as the final release. == Feedback == == Benefit to Fedora == Fedora aims to showcase the latest in free and open-source software - we should have the most recent release of Python 3. Packages in Fedora can use the new features from 3.16. There's also a benefit to the larger Python ecosystem: by building Fedora's packages against 3.16 while it's still in development, we can catch critical bugs before the final 3.16.0 release. == Scope == We will coordinate the work in a side tag and merge when ready. * Proposal owners: *# Introduce {{package|python3.16}} for all Fedoras *# Prepare stuff in Copr as explained in description. *# Update {{package|python-rpm-macros}} so {{package|python3.16}} builds {{package|python3}} *# Build {{package|python3.16}} as the main Python *# Mass rebuild all the packages that runtime require `python(abi) = 3.15` and/or `libpython3.15.so.1.0` (~3900 known packages in October 2026) *# Build {{package|python3.15}} as a non-main Python * Other developers: Maintainers of packages that fail to rebuild during the rebuilds will be asked, using e-mail and bugzilla, to fix or remove their packages from the distribution. If any issues appear, they should be solvable either by communicating with the respective upstreams first and/or applying downstream patches. Also, the package maintainers should have a look at: [https://docs.python.org/dev/whatsnew/3.16.html#porting-to-python-3-16 Porting to Python 3.16]. The python-maint team will be available to help with fixing issues. * Release engineering: [https://forge.fedoraproject.org/releng/tickets/issues/13552 #13552] * 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 == All the packages that depend on Python 3 must be rebuilt. User written Python 3 scripts/applications may require a small amount of porting, but mostly Python 3.15 is forward compatible with Python 3.16. Packages that fail to install because they failed to rebuild with Python 3.16 will be retired at Final Freeze unless they have a proposed Freeze Exception. == Early Testing (Optional) == Do you require 'QA Blueprint' support? No == How To Test == Interested testers do not need special hardware. If you have a favorite Python 3 script, module, or application, please test it with Python 3.16 and verify that it still works as you would expect. If the application you are testing does not require any other modules, you can test it using {{package|python3.16}} even before this change is implemented, in Fedora 43, 44, 45 or 46. In case your application requires other modules, or if you are testing an rpm package, it is necessary to install the 3.16 version of the python3 rpm. That rpm will shortly be available in Copr, along with all other python packages that build successfully with python 3.16. See https://copr.fedorainfracloud.org/coprs/g/python/python3.16/ for detailed instructions on how to enable Python 3.16 Copr for mock. Once the change is in place, test if your favorite Python apps are working as they were before. File bugs if they don't. == User Experience == Regular distro users shouldn't notice any change in system behavior other than the Python 3 interpreter will be in version 3.16. == Dependencies == ~4300 packages depend on Python 3 and ~3900 packages need rebuilding when Python is upgraded. See scope section. == Contingency Plan == * Contingency mechanism: Do not merge the side tag with rawhide. If the side tag has been merged and issues arise, that will justify a downgrade, then use an epoch tag to revert to 3.15 version (never needed before) * Contingency deadline: Beta Freeze * Blocks release? Yes, we'd like to block Fedora 47 release on at least 3.16.0rc1 == Documentation == [https://peps.python.org/pep-0826/ Python 3.16 Release Schedule] [https://docs.python.org/dev/whatsnew/3.16.html What's new in 3.16] == 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: PHP 8.6 (self-contained)

Wiki - https://fedoraproject.org/wiki/Changes/php86 Discourse Poll - https://discussion.fedoraproject.org/t/f46-change-proposal-php-8-6-self-contained/206303/2 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 == Update the PHP stack in Fedora to the latest version 8.6.x == Owner == * Name: [[User:Remi| Remi Collet]] and [[SIGs/PHP|PHP SIG]] * Email: remi at fedoraproject dot org == Current Status == * A testing SCL and a testing module are available in my [https://blog.remirepo.net/post/2026/09/30/PHP-on-the-road-to-the-8.6.0-release repository] * List of [https://github.com/remicollet/remirepo/issues/342 extensions compatibility list] * [https://wiki.php.net/todo/php86 Upstream schedule for 8.6] * 2025-09-24: PHP 8.6.0RC2 tagged with final API/ABI * 2025-10-08: PHP 8.6.0RC3 tagged == Detailed Description == Update the PHP stack in Fedora to latest version 8.6.x. Fedora has a 6-month cycle, PHP a 1-year cycle, our common practice for some years: * 2 Fedora cycles for each PHP minor release (exceptions below) * 3 Fedora cycles for latest minor (e.g. 5.6 or 7.4) to give more time before next major * 1 Fedora cycle for first major (e.g. 7.0 or 8.0) Fedora 43 have PHP 8.4, Fedora 44 and 45 have PHP 8.5. As this version should be the last 8.x (before 9.0), it should be in Fedora 46, 47 and 48. If the PHP project chooses to do an 8.8, it should land in 48. == Benefit to Fedora == Provides the latest PHP version to developers and system administrators. == Scope == * Proposal owners: Check Koschei status. Test with latest version to ensure compatibility. Work with upstream on bug fixing. Needed mass rebuild (C extensions) done by change owner. * Other developers: 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 == N/A (not a System Wide Change) == How To Test == * The PHP stack (extensions and libraries) are monitored by Koschei, see the [https://apps.fedoraproject.org/koschei/groups/php?order_by=state%2C-started Koschei PHP group] * install and play with your web applications == User Experience == Developers and system administrators will have the great benefit or running the latest PHP version. == Dependencies == All php-* packages (and some *-php) == Contingency Plan == * Contingency mechanism: Drop not compatible (and not fixable) packages. * Contingency deadline: N/A (not a System Wide Change) * Blocks release? N/A (not a System Wide Change) * Blocks product? product == Documentation == * [https://raw.githubusercontent.com/php/php-src/PHP-8.6/UPGRADING UPGRADING] (PHP 8.6 upgrade notes) * [https://raw.githubusercontent.com/php/php-src/PHP-8.6/UPGRADING.INTERNALS UPGRADING.INTERNALS] (PHP 8.6 internals upgrade notes) <!-- * [https://www.php.net/releases/8.5/en.php Key Features in PHP 8.5] (Release page) --> == 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

REMINDER: F45 Final Go/No-Go Meeting Tomorrow, Oct 29

Hi all,


This is a reminder that the F45 Final Go/No-Go meeting is scheduled for tomorrow, 29 Oct 2026 @ 1800 UTC in #fedora-meeting on Matrix.

In this meeting, we will determine the status of the release candidate for F45 Final.

For more information on this meeting, please visit
https://fedoraproject.org/wiki/Go_No_Go_Meeting


Source: https://calendar.fedoraproject.org/meeting/11450/

--

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, October 26, 2026

Register Today for the Fall FreeBSD Vendor Summit

Reminder! The Fall 2026 FreeBSD Vendor Summit takes place November 5th-6th, 2026, at NetApp’s San Jose campus. If you'd like a printed badge, please register no later than Tuesday, October 27.

Thank you to our Venue Sponsor, NetApp, and our Gold Sponsor, The
FreeBSD Foundation.

The program will include:

    - Carmi Weinzweig, RFC Holdings, Inc. and Texas A & M and Kevin Engle,
      V3 Entertainment, Inc. on “State of Cloud Native Computing on FreeBSD:
      OCI containers, Kubernetes and LLMs”
    - An Introduction from the recently-elected FreeBSD Core Team
    - Amy Vargas, NetApp, on "NetApp's Journey of Upstreaming to FreeBSD"
    - Mark Johnston from the FreeBSD Project on “Discovering FreeBSD
      vulnerabilities with AI”
    - Slava Shwartsman, NVIDIA on “Supporting DOCA on FreeBSD”
    - A lightning talk session on Friday

Attendees can still submit lightning talk proposals to jhb@freebsd.org or
devsummit@FreeBSD.org.

An on-campus reception will take place following the conclusion of the
meeting sessions on Thursday, November 5th.

The summit is open to the public, and there is a registration fee of US
$150.

Additional details on travel and lodging suggestions are available here:
https://freebsdfoundation.org/news-and-events/event-calendar/november-2026-freebsd-vendor-summit/

Looking forward to seeing you next month in San Jose!

--
Anne Dickison
Deputy Director
FreeBSD Foundation

510.332.8323

Friday, October 23, 2026

Re: F45 Final is NO-GO


Aoife Moloney

Fedora Operations Architect

Fedora Project

Matrix: @amoloney:fedora.im

IRC: amoloney



On Thu, 22 Oct 2026, 20:48 Aoife Moloney, <amoloney@redhat.com> wrote:
Due to outstanding blocker bugs[1], F45 Final RC-1.2 was declared NO-GO in today's Go/No-GO meeting[2].

The next Fedora Linux 45 FinalGo/No-Go meeting[3] will be held at 1700
UTC on Thursday , 29 October in #fedora-meeting on Matrix. We will aim for the
"target date #2" milestone of 2026-11-03. The release schedule[4] has
been updated accordingly.

[1] https://qa.fedoraproject.org/blockerbugs/milestone/44/final/buglist
[2] https://meetbot.fedoraproject.org/meeting_matrix_fedoraproject-org/2026-10-22/f45-final-go-no-go-meeting.2026-10-22-17.00.html
[3] https://calendar.fedoraproject.org/meeting/11450/
[4] https://fedorapeople.org/groups/schedule/f-45/f-45-key-tasks.html
--

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

Thursday, October 22, 2026

LibreSSL 4.3.4 and 4.2.3 released

We have released LibreSSL 4.3.4 and 4.2.3, which will be arriving in the LibreSSL directory of your local OpenBSD mirror soon. * Security fix - Removed eMudhra emSign ECC Root CA - G3 from cert.pem because of weak keys of some subordinate CAs. For purposes of interoperability, uncompromised intermediates were added. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.

LibreSSL 4.4.0 released

We have released LibreSSL 4.4.0, which you can find in the LibreSSL directory of your local OpenBSD mirror. This is the first stable release of the 4.4.x branch, also available with OpenBSD 8.0 It includes the following changes from LibreSSL 4.3.0: * Security fix: Removed eMudhra emSign ECC Root CA - G3 from cert.pem because of weak keys of some subordinate CAs. For purposes of interoperability, uncompromised intermediates were added. Upgrade note: Reinstalls no longer overwrite cert.pem, so this may need a manual merge if your package manager does not take care of this. 'CN=emSign ECC Root CA - G3' should not appear in cert.pem. * Portable changes - Fixed nc(1) network functionality on macOS. - Enabled control flow protection for assembly with CMake. - Fixed building on AIX, which lacks vsyslog(). - Fixed incorrect SHA-3 and SHAKE output on AIX with compilers that do not define __BYTE_ORDER__. - Fixed building with newer llvm-mingw, which now ships endian.h. - Added support for building on macOS Golden Gate, 27.0 - Fixed incorrect code generation by the MSVC ARM64 optimizer in constant-time bignum code. - Enabled assembly on MSVC x64 with CMake generators that were not detected as 64-bit, such as "NMake Makefiles". - Enabled SHA assembly on ELF AArch64 with CMake. - Enabled bignum assembly on RISC-V with autotools. - MIPS32 and MIPS64 assembly can be explicitly enabled. - The CMake build now applies the same exploit-mitigation compiler and linker flags as the autotools build. - Autotools hardening flag detection now honors user-supplied CFLAGS/LDFLAGS. - Fixed default OPENSSLDIR on MinGW autotools builds to use a valid absolute path. - Fixed CMake setting TLS_DEFAULT_CA_FILE to a relative path, and allow overriding TLS_DEFAULT_CA_FILE in CMake builds. - Reinstalling no longer overwrites an existing cert.pem, openssl.cnf and x509v3.cnf. - CMake builds now use the builtin arc4random on older macOS, FreeBSD and NetBSD releases with weakly seeded arc4random. - Fixed openssl(1), nc(1) and ocspcheck(1) silently running without pledge and unveil on hosts that provide them. - nc(1) now reports an error when -m minttl is not supported, rather than silently ignoring it. - readpassphrase() now sets close-on-exec on the tty descriptor. - Fixed buffer overflows in the getdelim() compatibility function. - Windows compatibility layer fixes: - Changed struct timeval on MSVC to match winsock, fixing memory corruption in DTLSv1_get_timeout() and the datagram BIO timeout controls. - poll() now waits for the requested timeout instead of returning early, reports failed connects as POLLERR and returns errors instead of timeouts. This fixes openssl(1) s_client, s_server and ocsp spinning or missing errors. - connect() reports EINPROGRESS for non-blocking connections. - accept4() honors SOCK_NONBLOCK. - read() and write() no longer truncate lengths of 2 GiB or more. - pread() and pwrite() restore the file offset on error. - ftruncate() and fdopen() work on descriptors from open(), fixing tls_load_file() with a password. - socketpair() emulation now verifies its peer, and sets close-on-exec on the right handle. - Socket errors without an explicit mapping now set errno. - Fixed a double free in pthread_mutex_destroy(). - Fixed a resource leak in openssl(1) speed. - snprintf() is always NUL-terminated on pre-2015 MSVC. - Fixed an out-of-bounds write in opendir() and error handling in getprogname(). * Internal improvements - Minor code cleanup for PKCS#7. - Clear unused bits for the maximum of RFC 3779 IP address ranges. - Cleanup passes over the DTLS code, avoiding many contortions. - Zero out the failure_key in ML-KEM code. - Improve portability in preprocessor based SHA assembly. - Removed a few vestigial #ifdefs from public and internal headers. - Introduce and use dtls12_handshake_msg framework. - Rename union from _ to u in the ui code. Avoids Windows CE #ifdef. - Clean up and simplify signature algorithm handling after removal of TLSv1.0 and TLSv1.1. - Add a point at infinity check to ecdh_compute_key(). - Fix incorrect purpose check in unreachable non-legacy path of the modern X.509 verifier. - Improve TLSv1.3 server handling of no shared groups. - Correct secondary key share handling for HelloRetryRequests. - Fix EXFLAG_CRITICAL mishandling in the crl_cb(). - Among CRLs with the same score prefer the one with the most recent thisUpdate to match BoringSSL and OpenSSL behavior. - Clean up sequence number and message header handling in DTLS. - Remove redundant BIO_write() length assertions in b64_write(). - Report invalid base64 BIO state as an internal error rather than asserting. - Improve SHA-3 performance by using an unrolled and interleaved algorithm. - Allocate TLSv1.3 receive buffers lazily. - Simplify handling of remaining record content on switch to the legacy stack. - Avoid harmless narrowing of the return value in dtls1_ctrl(). - Remove NID_md5_sha1 support from tls1_PRF(). - Remove DTLS unprocessed records queue. - Remove DTLS application data queue. - Remove SSL3_FLAGS_NO_RENEGOTIATE_CIPHERS which was never set. * Compatibility changes - The misnamed tls_peer_cert_chain_pem() has been deprecated and may be removed in a future release. tls_peer_cert_chain_verified_pem() and tls_peer_cert_bundle_unverified_pem() should be used instead. - Use X25519MLKEM768 as the preferred group for TLSv1.3 connections in libtls. - Ensure libtls keeps working with future OpenSSL releases that will stop NUL-terminating ASN.1 strings. This is an old bug in libtls that will bite, probably starting with OpenSSL 4.2. - CRYPTO_cleanup_all_ex_data() is now a no-op. It was not thread safe and the actual cleanup is now done by OPENSSL_cleanup(). - Align X509_check_ca() with modern OpenSSL. While it has long been documented that it only works after calling X509_check_purpose(), it still makes sense to "fail closed", i.e., indicate a non-CA. - Added OIDs for CCR, ErikIndex, ErikPartition, ErikSegmentIndex, and communityDefinition. * Bug fixes - Fix PKCS7_set_{un,}signed_attributes() to allow caller to free on failure rather than risking a double free. - Initialize decode_error and invalid_key variables in TLS key share code to avoid branching on uninitialized memory. - Record extension length between type and data in the ClientHello hash to ensure identical framing in first and second CH. - Fix out of bound writes in the s_client XMSS mode. - Ensure EC_GROUP_check and X509_CRL_verify failures result in "app" failures in openssl ecparam and openssl crl. - Do not fail accept on reverse DNS lookup failures in s_socket. - Ensure X509V3_EXT_print() only returns 0 and 1. - Avoid calling memcmp() on NULL in IPAddressFamily_cmp(). - In libtls disallow wildcard matching of a TLD specified as a FQDN. - Unbreak some aspects of TLSv1.2 with custom curve lists. - Ensure a peer-provided EC public key uses uncompressed encoding. - Send decode_error alert on failure to decode an EC peer pubkey. - Avoid NULL dereference and out-of-bounds read in password-based CMS decryption. - Add some missing bounds check to ASN1_mbstrinc_copy(). - Avoid freeing a caller-owned buffer in PKCS7_verify(). - Remove SSL_OP_LEGACY_SERVER_CONNECT from default options. - Send illegal parameter alerts for various HelloRetryRequest violations. - Check that the server selected ciphersuite is valid for use with TLSv1.2. - Unlock CRYPTO_LOCK_UI on ui_open_session() failure to avoid a deadlock. - Check HMAC() return value to avoid later use of uninitialized in openssl(1). - Use correct alert for key_share without supported_groups. - Don't drop X509_V_ERR_HOSTNAME_MISMATCH when verify callback returns 1. It has long been documented that this is ill advised but some applications still do it. - Ensure the server selects an ALPN protocol that we advertised or abort the handshake with illegal_parameter. - Fix streaming of PKCS#7 objects with omitted content. - Avoid OOB access due to type confusion in PKCS7_stream() - Plug leak and various other bugs in asn1_multi(), a helper to handle sequences and sets in config parsing. - Fix RFC 3779 inheritance checks for leaves as far as possible without breaking the RPKI. Still allow the immediate issuer to omit one of the extensions because otherwise about one third of RFC 9286 Manifests would become invalid. - Correct a botched size check in dtls1_process_fragment() - Avoid confusing delta CRLs as full CRLs. - When copying an RSA-PSS EVP_PKEY_CTX, ensure saltlen and minimal saltlen restrictions are copied rather than using the defaults. - Allow DTLS clients to receive unexpected Finished messages. - Cache the leaf's extensions before adding it to a validated chain to make name constraints check work more reliably. - Ensure the whole subject is searched for email addresses and common names. - Check for embedded NULs in emails and subjectAltname in the essentially unused legacy NAME_CONSTRAINTS_*() API. - Remove support for nameRelativeToCRLIssuer in the CRL Distribution Point extension. Per RFC 5280 it SHOULD not be used by conforming CAs and it was eating memory for breakfast pre-signature. * Security and reliability fixes - Fix parsing issues in X.509 name constraints URI host parsing. Handle IPv6 literals correctly and don't allow specially crafted userinfo to bypass host checks. - Limit size of buffered DTLS handshake messages to avoid overly large memory consumption on small handshake message fragments. - Fix an OCSP responder authorization bypass for clients using tls_config_ocsp_require_stapling(), of which only OpenBSD nc(1) and ftp(1) are known when they're used with the "muststaple" key word. * Testing and proactive security - Improved test coverage for DTLS and TLS renegotiation. - Add X.509 CRL regress from pre-Apache2-licensed BoringSSL. - Rework the testing framework to be memory based rather than file based. Match Go's output format more closely. The LibreSSL project continues improvement of the codebase to reflect modern, safe programming practices. We welcome feedback and improvements from the broader community. Thanks to all of the contributors who helped make this release possible.

Re: s390x improvements progress and plans

On Thu, 2026-10-08 at 11:01 -0700, Kevin Fenzi via devel-announce wrote: > Greetings. > > As you know there have been issues around slowness and lack of > resources for s390x builds. > See https://forge.fedoraproject.org/infra/tickets/issues/13141 and > https://forge.fedoraproject.org/fesco/tickets/issues/3688 > > We have recently been working with IBM to try and solve those issues, > and I wanted > to share actions already taken and plans moving forward. > > Shorter term IBM has gathered a bunch of information about our setup > and > made some adjustments to our LPAR as well as allowing Infrastructure > to make > adjustments based on their reccommendations. This includes: > > * Our LPAR has been allocated more memory. This has allowed us to > give >   more memory to builders as well as allowing us to finally move to > newer >   kernels on the hypervisor ( > https://bugzilla.redhat.com/show_bug.cgi?id=2492031 ) > * The LPAR has had it's CPU weight adjusted to increase processor > time > * Some builders have had cpus added to them, allocating more from our > existing >   CPU pool. > * We have setup to gather more data for IBM to review. After some > more heavy >   build times this will hopefully inform them on any additional steps > we can >   take with the existing LPAR/resources. >   > Medium term, we are discussing the idea of more resources in another > mainframe > in another location. This discussion is ongoing and we will see if > something > can be found. > > Longer term of course we are working to improve the existing env and > increase capacity. > > So, progress is being made and hopefully there is some short term > improvements > as well as possible medium term ones on the horizion. > Looks like it does have the expected result! I crunched some numbers and did a TL;DR here https://forge.fedoraproject.org/fesco/tickets/issues/3688#issuecomment-1367964 (there is a link to a PDF report, or here to save you a redirection: https://github.com/slopfest/sandogasa/releases/download/koji-lag-store-2026-10-19/FINDINGS.pdf ) One thing that surfaced after I crunched all the data: I could have used hw_info.log to get hardware data for the builders used for specific jobs, but I'm about to be AFK for a few days and ran out of time to redo the analysis, so expect the updated data later. But that means some of the open questions listed in the findings can be answered in the next pass. Thanks nirik for all the work here! Best regards, --  _o) Michel Lind _( ) https://keyoxide.org/5dce2e7e9c3b1cffd335c1d78b229d2f7ccc04f2

-- _______________________________________________ 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

OpenBSD Errata: October 23, 2026 (dbupdate)

Errata patches containing new dbupdate and updated cert.pem have been released for OpenBSD 7.9 and 8.0. Binary updates for the amd64, arm64 and i386 platform are available via the syspatch utility. Source code patches can be found on the respective errata page: https://www.openbsd.org/errata79.html https://www.openbsd.org/errata80.html