F41 Change Proposal: Make OpenSSL distrust SHA-1 signatures by default (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/OpenSSLDistrustSHA1SigVer Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-make-openssl-distrust-sha-1-signatures-by-default-system-wide/119457 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 == OpenSSL will no longer trust cryptographic signatures using SHA-1 by default, starting from Fedora 41. == Owner == * Name: [[User:Asosedkin| Alexander Sosedkin]] * Email: asose...@redhat.com == Detailed Description == We would like to deprecate SHA-1 in signatures, because chosen-prefix collision attacks on SHA-1 are becoming increasingly feasible. Specifically, https://sha-mbles.github.io claims a complexity of 2^63.4, and a cost of 45k US dollars, with an estimated cost of 10k US dollars by 2025 to find a chosen-prefix collision for a SHA-1 signature. With this change accepted and implemented, OpenSSL will start blocking SHA-1 signature creation and verification by default. The rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]] has previously included this change among several others. This is a second attempt to propose it, two years later, with a narrower scope. == Feedback == This change, when discussed as part of the rejected [[ Changes/StrongCryptoSettings3 | Changes/StrongCryptoSettings3 ]], has proved itself controversial. There seems to be a consensus that the change has to be done sooner or later, but Fedora is a remarkably conservative distribution when it comes to deprecating legacy cryptography, even if by-default-only. The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but it's not like many viable alternative proposals have been raised in return either. In particular, there is no suitable facility to perform opt-out logging of the deprecated operation. Opt-in logging through USDT probes has been implemented the last time and has been reinstated again to aid testing this change. The precursor change has received limited testing during Fedora 37 Test Days, with only a handful of bugs discovered. The ones that were, though, wouldn't be something realistically discoverable by other means. The change has received significant testing in RHEL, which distrusts SHA-1 signatures by default starting from RHEL-9. Having this switch flipped in RHEL for ~2 years further enforces our confidence in the change. == Benefit to Fedora == Fedora's security defaults will inch closer to what is considered secure in the modern-day cryptographic landscape. == Scope == * Proposal owners: flip that switch in the DEFAULT policy, provide transitional policies for testing the change. * Other developers: Test your applications under TEST-FEDORA41 policy. If the security of your application depends on trusting SHA-1 signatures, fix this, or it will stop working unless users explicitly opt into lower security guarantees. See [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. * Release engineering: [https://pagure.io/releng/issue/12096 #12096] A change is a runtime change, so the mass rebuild considerations boil down to %check-time testsuite failures expecting different defaults. Specifically, reverting the change can be safely done without a mass-rebuild. * Policies and guidelines: CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default. * Trademark approval: N/A (not needed for this Change) * Alignment with Community Initiatives: == Upgrade/compatibility impact == The change is not expected to break upgrades themselves. The ways people use Fedora are a multitude, and the rare scenarios relying on trusting SHA-1 signatures will break. Administrators willing to retain previous behavior and sacrifice security will be able to apply a compatibility policy or subpolicy before or after the upgrade. == How To Test == Preview the new defaults with `update-crypto-policies --set TEST-FEDORA41`. Proceed to use the system as usual, identify the workflows which are broken by blocking SHA-1 signature creation/verification, ideally also verify that `update-crypto-policies --set DEFAULT` fixes them, file bug reports against the affected components if not filed already. Please start your ticket title with `OpenSSLDistrustSHA1SigVer: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work. Alternatively, a tool to identify the affected operation without blocking them will likely be provided, installable from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer. One would need openssl-3.2.1-9.fc41 or newer for the tool to work. == U
Re: F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
Missing link for discussion thread https://discussion.fedoraproject.org/t/f41-change-proposal-remove-ifcfg-support-in-networkmanager-system-wide/119455 -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Remove ifcfg support in NetworkManager (system-wide)
Wiki - https://fedoraproject.org/wiki/Changes/RemoveIfcfgSupportInNM Discussion Thread - 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 == Remove support for connection profiles stored in ifcfg format in NetworkManager. == Owner == * Name: [[User:bengal| Beniamino Galvani]], [[User:ffmancera| Fernando Fernández Mancera]], [[User:Till| Till Maas]] * Email: , , == Detailed Description == NetworkManager supports different formats to persist connection profiles to disk. The two formats currently in use in Fedora are ''keyfile'' and ''ifcfg''. [https://networkmanager.dev/docs/api/latest/nm-settings-keyfile.html Keyfile] is the native and preferred format. It supports all the connection types and all the features. [https://networkmanager.dev/docs/api/latest/nm-settings-ifcfg-rh.html Ifcfg] is compatible with the old network-scripts. It only supports a limited set of connection types, and it is [https://lists.freedesktop.org/archives/networkmanager/2023-May/000103.html deprecated] upstream. This change proposal aims at removing NetworkManager support for ifcfg files in Fedora. This is the last step of a process started several releases ago: * in Fedora 33, the default connection format was changed from ifcfg to keyfile; * in Fedora 36, the plugin that handles ifcfg files was shipped in a separate package and was not included in new installations; * since Fedora 39, the NetworkManager daemon automatically migrates ifcfg files to the keyfile format. == Benefit to Fedora == Since ifcfg support is going to be removed upstream, it must also be removed in Fedora. Keyfile is a valid and better replacement. == Scope == * Proposal owners: drop the following packages: ** `NetworkManager-initscripts-ifcfg-rh` containing the ifcfg plugin ** `NetworkManager-dispatcher-routing-rules` containing a dispatcher script to apply routing rules in ifcfg format ** `NetworkManager-initscripts-updown` containing alternative ifup/ifdown scripts compatible with initscripts commands, using NetworkManager. * Other developers: N/A * Release engineering: N/A * Policies and guidelines: N/A * Trademark approval: N/A == Upgrade/compatibility impact == At this point no users should have connection profiles stored in ifcfg format, as NetworkManager is automatically migrating them to keyfile since Fedora 39. According to [https://docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-offline documentation] , system upgrades are supported only over 2 releases at most (e.g. from 38 to 40); therefore, users upgrading to Fedora 41 must come from Fedora 39 or 40, which have the migration enabled. If some users disabled the migration, they might still have ifcfg files in `/etc/sysconfig/network-scripts`. A “readme-ifcfg-rh.txt” file there warns users that the format is deprecated and is going to be removed. == How To Test == * Try to install the NetworkManager-initscripts-ifcfg-rh package * The package is not available. == User Experience == See the “Upgrade/compatibility impact” section. == Dependencies == None == Contingency Plan == * Contingency mechanism: Revert the change, try again the next Fedora release. * Contingency deadline: Beta freeze * Blocks release? no == Documentation == No documentation change required. == Release Notes == The change needs to be mentioned in the 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-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Separate package for dtrace from systemtap-sdt-devel (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/Separate_dtrace_package
Discussion Thread -
https://discussion.fedoraproject.org/t/f41-change-proposal-separate-package-for-dtrace-from-systemtap-sdt-devel-self-contained/119451
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 ==
Split /usr/bin/dtrace from
systemtap-sdt-devel ({{package|systemtap}}) into a
separate package to optimize many buildroots by removing unnecessary
Python dependencies.
== Owner ==
* Name: [[User:lbalhar| Lumír Balhar]]
* Email: lbal...@redhat.com
== Detailed Description ==
The package systemtap-sdt-devel currently contains header
files and the script /usr/bin/dtrace, which is written in
Python and uses pycparser. This results in unnecessary Python and
pycparser installations for many packages that do not need the script
(and many times Python at all), as they only require the header files.
Moreover, some important packages (like perl-devel) require
systemtap-sdt-devel which means hundreds of Perl packages have Python
installed in their buildroots because of the single script they don't
need.
The idea was tested on all packages build-requiring perl-devel but
don't build-requiring python-devel directly - 520 in total. And from
that number:
* 7 failed to build for unrelated reasons
* 3 packages have python3-devel in buildroot (different reasons than
systempat-sdt-devel)
* 81 packages have python3-libs but not python3-devel (different
reasons than systemtap-sdt-devel)
and finally, the rest - 436 packages - builds fine without the Python
script in systemtap-sdt-devel and therefore without Python at all.
Further testing on packages directly requiring systemtap-sdt-devel
identified the following needing the dtrace script:
* glib2
* sssd
* qemu
* python2.7
* postgresql15
* postgresql16
* perl
* php
* mariadb10.11
* libvirt
Those will depend on a new package to which we move the script.
== Feedback ==
The proposal has been positively received on the
[https://lists.fedorahosted.org/archives/list/de...@lists.fedoraproject.org/thread/4HKXN77BMFHRMXC7BU2HXECIKOI7B6CS/#4HKXN77BMFHRMXC7BU2HXECIKOI7B6CS
Fedora devel list].
== Benefit to Fedora ==
By splitting the /usr/bin/dtrace script into a separate
package, we reduce the buildroot size and improve build times for
hundreds of packages that do not require Python.
== Scope ==
* Proposal owners:
# Move the script to a new package systemtap-sdt-dtrace
and update systemtap-sdt-devel to require this new
package for backward compatibility.
# Update affected packages to depend on systemtap-sdt-dtrace.
# Remove the backward-compatible requirement from
systemtap-sdt-devel.
* Other developers: Review and merge proposed changes, and report any bugs.
* Release engineering: N/A (not needed for this Change)
* Policies and guidelines: N/A (not needed for this Change)
* Trademark approval: N/A (not needed for this Change)
* Alignment with the Fedora Strategy: N/A (not needed for this Change)
== Upgrade/compatibility impact ==
== How To Test ==
Package maintainers can proactively prepare their packages after the
first step from the plan above is implemented. Failed builds
identifying packages requiring changes are available in
[https://copr.fedorainfracloud.org/coprs/lbalhar/sdt-devel-no-dtrace/
COPR].
Maintainers can also build and test their packages with the version of
systemtap-sdt-devel from which the script has been removed.
== User Experience ==
Regular distro users shouldn't notice any change.
== Dependencies ==
== Contingency Plan ==
* Contingency mechanism: Change owner will revert the change in
{{package|systemtap}}.
* 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-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
F41 Change Proposal: Wayland-only GNOME Workstation Media (self-contained)
Wiki - https://fedoraproject.org/wiki/Changes/WaylandOnlyGNOMEWorkstationMedia Discussion Topic - https://discussion.fedoraproject.org/t/f41-change-proposal-wayland-only-gnome-workstation-media-self-contained/119447 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 == Remove the GNOME X11 packages from the Fedora Workstation media. The packages will remain available in the repositories maintained by the GNOME SIG, but not preinstalled on the media anymore. == Owner == * Name: [[User:Ngompa| Neal Gompa]] * Email: ngomp...@gmail.com == Detailed Description == As part of the upstream deprecation and effort to remove X11 support from GNOME, Fedora Workstation media will no longer include the GNOME X11 packages. The packages will remain in the repository (maintained by the GNOME SIG/Workstation WG) for users to manually install at this time. == Feedback == == Benefit to Fedora == This aligns us with the effort going on upstream to deprecate and retire the GNOME X11 session. It also partly aligns us with Fedora KDE. Like the Fedora KDE SIG, the Fedora Workstation WG recommends and supports the Wayland platform for graphics. Fedora Workstation has a long history of developing and promoting the Wayland experience for GNOME, and [https://fedoraproject.org/wiki/Changes/WaylandByDefaultOnNVIDIA it has been the primary experience for all users (including those with NVIDIA cards) since Fedora Linux 36]. This reaffirms our commitment to the Wayland GNOME experience in furtherance of the goal to provide the highest quality GNOME experience through Fedora Workstation. == Scope == * Proposal owners: Drop the GNOME X11 packages from the GNOME groups in comps and replace them with their Wayland counterparts. Pull request: [https://pagure.io/fedora-comps/pull-request/972 pagureio#fedora-comps#972] * Other developers: N/A (not needed for this Change) * Release engineering: N/A (not needed for this Change) * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with the Fedora Strategy: N/A (not needed for this Change) == Upgrade/compatibility impact == Systems upgrading from older releases of Fedora Workstation will not be impacted, as this only affects new installs. == Early Testing (Optional) == Not applicable to this change. == How To Test == Not applicable to this change, as we're only dropping a non-default experience from the media. == User Experience == Going forward until the X11 session packages are fully dropped, users will need to manually install them from the repository if they need it. == Dependencies == Not applicable for this change. == Contingency Plan == * Contingency mechanism: Revert the comps change * Contingency deadline: Final freeze * Blocks release? Yes. == Documentation == N/A (not a System Wide Change) == Release Notes == Fedora Workstation no longer pre-installs the deprecated GNOME X11 session for new installations. Users who wish to add it back can do so by installing the gnome-session-xsession and gnome-classic-session-xsession packages. -- 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-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
Fedora 41 Python 3.13 rebuild in a side tag has now started
Hello, We have just started the Python 3.13 mass rebuild in the side tag for Fedora 41 with Python 3.13.0b2. Please, follow the original instructions when planning to build your Python packages. We'll let you know when we'll plan to merge the side tag. And... keep your fingers crossed :) Karolina On 5/31/24 10:55, Karolina Surma wrote: Hello, To deliver Python 3.13 with Fedora Linux 41, we will run a coordinated rebuild in a side tag. https://fedoraproject.org/wiki/Changes/Python3.13 Python 3.13.0b2 is scheduled for Tuesday, Jun 4th 2024. We hope to start the mass rebuild shortly after it's available. TL;DR: If you can, for the period of the mass rebuild just don't build your packages in rawhide. We will let you know when the side tag rebuild actually starts and when it is merged and it's safe to build in rawhide with Python 3.13. Details: If you see a "Rebuilt for Python 3.13" (or similar) commit in your package, please don't rebuild it in regular rawhide or another rawhide side tag. If you need to, please let us know, so we can coordinate. If you'd like to build a package after we already rebuilt it, you should be able to build it in the side tag via: on branch rawhide: $ fedpkg build --target=f41-python $ koji wait-repo f41-python --build It takes time to build all the essential packages, so don't expect all your dependencies to be available right away. Any attempts to build your packages in the side tag before we do will likely fail due to missing dependencies. When in trouble, ask here or on Fedora's Matrix - Fedora Python room (https://matrix.to/#/#python:fedoraproject.org) Ping me (ksurma) or Miro (mhroncok) if you need to talk to us. Builds will appear here: https://koji.fedoraproject.org/koji/builds?latest=0&tagID=f41-python&order=-build_id&inherited=0 Please avoid any potentially disturbing or major changes in Python packages until the rebuild is over. Thanks! Karolina -- ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
