devel April 2022

devel@lists.fedoraproject.org

201 participants
367 discussions

Minizip pull requests
by Julian Sikorski 10 Jun '22

10 Jun '22

Hello, I have created two PRs against minizip which are yet to be merged: - https://src.fedoraproject.org/rpms/minizip/pull-request/3 - https://src.fedoraproject.org/rpms/minizip/pull-request/4 The first one should be a low risk one and should allow pkg-config using dependencies like (shameless self-interest plug) to build against system minizip again. The second one needs support from a provenpackager. I tried rebuilding the 18 dependencies of minizip and this is a bit tricky for two reasons: - libsmbl and libspatialite need to be rebuilt before the other dependencies - I cannot figure out how to get fedpkg srpm to work with libspatialite, I am getting a Package already exists: %package debuginfo error from the %{?mingw_debug_package} line. I am sure this is something someone familiar with mingw can fix in a shortest amount of time. Other than that, I can confirm that 13 dependencies can be rebuilt with no changes. How can we move this forward? Best regards, Julian

2 2

Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS
by py0xc3 08 Jun '22

08 Jun '22

Good everning, I just experienced that, when setting up a new Fedora, Anaconda (both "Custom" and "Advanced Custom (Blivet-GUI)") always uses aes-xts-plain64 for disk encryption, even if the hardware does not support AES-NI. Does it make sense to use xchacha12,aes-adiantum-plain64 by default if there is no AES-NI in the hardware? For a general use case, the security advantages of Adiantum can be neglected; both aes-xts & chacha-adiantum are secure. But there are big performance disadvantages of AES when there is no AES-NI (this was the major reason for merging Adiantum into the kernel). Besides the use of system resources, netbooks and such may have strongly decreased battery life times with aes-xts (the issue is primarily aes, not xts). I tested with Fedora 35, KDE spin; but as the issue is Anaconda-centric, I expect that other Workstation installations tend to the same behavior. Adjustments would be limited to Anaconda. Regards & stay safe, Chris

3 3

F37 Change: Replace jwhois package with whois for Fedora Workstation (Self-Contained Change proposal)
by Ben Cotton 03 Jun '22

03 Jun '22

https://fedoraproject.org/wiki/Changes/Replace_jwhois_with_whois_in_Fedora_… == Summary == Fedora Workstation product core group includes `jwhois` package. Replace it with `whois` package which is more actively developed. == Detailed Description == `Fedora Workstation product core` group includes `jwhois` package. Its last commit is [http://www.gnu.org/software/jwhois/ from 2015]. Users having issues with certain TLDs and the solution is usually manually editing the `/etc/jwois.conf` file. `whois` package is [https://github.com/rfc1036/whois more actively maintained] and doesn't have those issues. == Benefit to Fedora == Users will have a better experience querying `whois` information for a domain. == Scope == * Proposal owners: * Other developers: * Release engineering: [https://pagure.io/releng/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 Objectives: == Upgrade/compatibility impact == == How To Test == * Run `rpm -q --whatprovides whois` * It should print `whois-*` == User Experience == == 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 == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

3 2

F37 Proposal: Strong crypto settings: phase 3, forewarning 1/2 (System-Wide Change proposal)
by Ben Cotton 31 May '22

31 May '22

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. https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning1 == Summary == Cryptographic policies will be tightened in Fedora 38-39, SHA-1 signatures will no longer be trusted by default. Fedora 37 specifically doesn't come with any change of defaults, and this Fedora Change is an advance warning filed for extra visibility. Test your setup with FUTURE today and file bugs so you won't get bit by Fedora 38-39. == Owner == * Name: [[User:Asosedkin| Alexander Sosedkin]] * Email: asosedki(a)redhat.com == Detailed Description == Secure defaults are an evermoving target. Fedora 28 had [[Changes/StrongCryptoSettings|StrongCryptoSettings]]. Fedora 33 had [[Changes/StrongCryptoSettings2|StrongCryptoSettings2]]. Fedora 39 should have [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]. The impact of one upcoming change, notably distrusting SHA-1 signatures, might be so profound we're smoothing the rollout in time to give developers and maintainers ample time to react: Fedora 36: * SHA-1 signatures are distrusted in FUTURE policy (opt-in) * TEST-FEDORA39 policy is provided * creating and verifying SHA-1 signatures is logged to ease reporting bugs '''Fedora 37 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning1]]''': * (was initially reserved to implement logging of SHA-1 signature operations) Fedora 38 [[Changes/StrongCryptoSettings3Forewarning3|StrongCryptoSettings3Forewarning2]]: * policies are updated, most notably * SHA-1 signatures are distrusted in DEFAULT policy * changes are reverted in branched f38 in time for Beta and do not reach users Fedora 39 [[Changes/StrongCryptoSettings3|StrongCryptoSettings3]]: * changes reach users The plan is subject to change if it goes sideways somewhere along the way. By Fedora 39, the policies will be, in TLS perspective: LEGACY MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.) Curves: all prime >= 255 bits (including Bernstein curves) Signature algorithms: SHA-1 hash or better (no DSA) Ciphers: all available > 112-bit key, >= 128-bit block (no RC4 or 3DES) Key exchange: ECDHE, RSA, DHE (no DHE-DSS) DH params size: >=2048 RSA params size: >=2048 TLS protocols: TLS >= 1.2 DEFAULT MACs: All HMAC with SHA1 or better + all modern MACs (Poly1305 etc.) Curves: all prime >= 255 bits (including Bernstein curves) Signature algorithms: with SHA-224 hash or better (not DSA) Ciphers: >= 128-bit key, >= 128-bit block (AES, ChaCha20, including AES-CBC) Key exchange: ECDHE, RSA, DHE (no DHE-DSS) DH params size: >= 2048 RSA params size: >= 2048 TLS protocols: TLS >= 1.2 FUTURE MACs: All HMAC with SHA256 or better + all modern MACs (Poly1305 etc.) Curves: all prime >= 255 bits (including Bernstein curves) Signature algorithms: SHA-256 hash or better (not DSA) Ciphers: >= 256-bit key, >= 128-bit block, only Authenticated Encryption (AE) ciphers Key exchange: ECDHE, DHE DH params size: >= 3072 RSA params size: >= 3072 TLS protocols: TLS >= 1.2 The flagship change this time will be distrusting SHA-1 signatures on the cryptographic library level, affecting more than just TLS. OpenSSL will start blocking signature creation and verification by default, with the fallout anticipated to be wide enough for us to roll out the change across multiple cycles with multiple forewarnings. In Fedora 36, 37 and 38 released distrusting SHA-1 signatures will be opt-in. In Fedora 38 rawhide and Fedora 39 distrusting SHA-1 signatures will happen by default. == Feedback == [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… A discussion] has been raised on fedora-devel, [https://lwn.net/Articles/887832 a summary] is available on LWN. A change has the potential to prove disruptive and controversial, with much effort being focused on stretching it out in time. There seems to be a consensus that the change has to be done eventually, but the ideal means of implementing it are in no way clear. The decision to discover code reliant on SHA-1 signatures by blocking creation/verification has not gathered many fans, but not many alternative proposals have been raised in return. A notable one, making the library somehow log the offending operations, has been incorporated in the proposal, though the effectiveness of it is yet to be seen in practice. Another notable takeaway point is the need to call for testing, which would be done in form of writing four Fedora Changes and testing SHA-1 signature distrusting during Fedora 37 & 38 Test Days. The change owner doesn't see the plan as an ideal one and continues to be open for feedback. == Benefit to Fedora == Fedora 39 will ship with more secure defaults to better match the everchanging landscape of cryptographic practices. TLS 1.0 / 1.1 protocol version will be disabled as they're [deprecated https://datatracker.ietf.org/doc/rfc8996] minimum key sizes will be raised to keep up with the computational advances etc. Distrusting SHA-1 signatures specifically is expected to trigger a topical distribution-wide crackdown on [https://eprint.iacr.org/2020/014 weak] cryptography, raising the security of the distribution moving forward. == Scope == * Proposal owners: implement changes described in Summary and Dependencies sections * Other developers: Test your applications with FUTURE policy. Move away from trusting SHA-1 signatures; ideally in time for F38 branch-off, for F39 release at the latest. Follow [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]: 1. move away from trusting SHA-1 signatures entirely, or 2. distrust them by default and require explicit user opt-in to use a workaround * Release engineering: Not sure if mass-rebuild is required if we land the change right after f38 branch-off. Maybe a "preview" mass-rebuild can be done with a special build in the Fedora 37 timeframe to cut down on Fedora 38 FTBFS. * Policies and guidelines: update needed in time for Fedora 38 CryptoPolicies section of the packaging guidelines will have to be updated to reflect that SHA-1 signatures must not be trusted by default and provide guidance for openssl and gnutls. Components using workaround APIs must not use them without explicit user opt-in and must be added to a list of applications using a workaround API. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: not with Fedora 37-era ones == Upgrade/compatibility impact == Nothing will change for Fedora 37 by default, the change is opt-in for now. == How To Test == === Testing actively === Install crypto-policies-scripts package and switch to a more restrictive policy with either `update-crypto-policies --set FUTURE` or `update-crypto-policies --set TEST-FEDORA39`. Proceed to use the system as usual, identify the workflows which are broken by this change. Verify that the broken functionality works again if you the policy is relaxed back with, e.g., `update-crypto-policies --set FUTURE:SHA-1`, file bug reports against the affected components if not filed already. Please start your ticket title with `StrongCryptoSettings3: `, mention this change page, the version of crypto-policies package and the policies under which your workflow does and does not work. === Testing passively === Install a special logging tool from https://copr.fedorainfracloud.org/coprs/asosedkin/sha1sig-tracer Run it and proceed to use your system. Once the tool notifies you about about soon-to-be-blocked SHA-1 signature operations, identify the component and actions leading to these operations, verify that repeating them leads to logging more entries. Ideally also verify that switching to a stricter policy breaks the workflow. File bug reports against the affected components if not filed already. Please start your ticket title with `StrongCryptoSettings3: ` and link to this change page. == User Experience == Things will break. All kinds of things depending on SHA-1 signatures, openly and secretly. * '''On Fedora 37 they'll break opt-in.''' * On Fedora 38 rawhide they'll break by default. * On Fedora 38 released they'll behave like in Fedora 37. * On Fedora 39 they'll break by default again, including the released version. == Dependencies == While it would be welcome, no reverse dependencies of openssl have to react in time for Fedora 37, where the change is opt-in preview only. For now, test, file bugs and spark discussions. A small coordinated change with openssl is required. == Contingency Plan == * Contingency mechanism: not needed for F37 * Contingency deadline: not needed for F37 * Blocks release? no == Documentation == Workaround API should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. Packaging guidelines should be modified accordingly. == Release Notes == https://pagure.io/fedora-docs/release-notes/issue/829 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

21 42

OpenJDK and unremoved directories
by Vitaly Zaitsev 25 May '22

25 May '22

Hello. I have a lot of unremoved directories and files in /usr/lib/jvm/: $ ls -l /usr/lib/jvm/ total 140 drwxr-xr-x. 5 root root 4096 Sep 10 14:32 java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 drwxr-xr-x. 3 root root 4096 Mar 14 2017 java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64 drwxr-xr-x. 3 root root 4096 Apr 21 2017 java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64 drwxr-xr-x. 3 root root 4096 Oct 25 2017 java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64 drwxr-xr-x. 3 root root 4096 Oct 25 2017 java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Jan 24 2018 java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Feb 6 2018 java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Mar 29 2018 java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 18 2018 java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 25 2018 java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64 drwxr-xr-x. 3 root root 4096 Apr 25 2018 java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jul 3 2018 java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jun 18 2018 java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Jul 23 2018 java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Sep 5 2018 java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 4 2018 java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 11 2018 java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64 drwxr-xr-x. 3 root root 4096 Oct 11 2018 java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Nov 29 2018 java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Nov 1 2018 java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Jan 14 2019 java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Feb 6 2019 java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Mar 26 2019 java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Apr 23 2019 java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64 drwxr-xr-x. 3 root root 4096 Apr 23 2019 java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Jul 31 2019 java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Oct 16 2019 java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64 drwxr-xr-x. 3 root root 4096 Oct 16 2019 java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64 drwxr-xr-x. 3 root root 4096 Jan 28 2020 java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64 drwxr-xr-x. 3 root root 4096 Mar 23 2020 java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 May 4 2020 java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64 drwxr-xr-x. 3 root root 4096 May 22 2020 java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Jul 17 2020 java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Jul 28 2020 java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64 drwxr-xr-x. 3 root root 4096 Oct 21 2020 java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64 lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11 lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk -> /etc/alternatives/jre_11_openjdk lrwxrwxrwx. 1 root root 41 Aug 31 18:50 jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 -> java-11-openjdk-11.0.12.0.7-4.fc34.x86_64 lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk -> /etc/alternatives/jre_openjdk I think the OpenJDK's scriplets need to be adjusted to remove everything. -- Sincerely, Vitaly Zaitsev (vitaly(a)easycoding.org)

2 1

grub2 BIOS booting iso and code
by Brian C. Lane 23 May '22

23 May '22

A huge thanks to Thomas Schmitt for posting xorrisofs arguments :) Here is a lorax PR switching to grub2 for BIOS and changing the layout of the iso as described in his post: https://github.com/weldr/lorax/pull/1226 And a Fedora 36 iso: https://bcl.fedorapeople.org/boot-grub2-f36.iso I've tested this with: - qemu bios -cdrom - qemu uefi -cdrom - qemu bios -hda - qemu uefi -hda - USB stick on uefi PC hardware with SB off - USB stick on UEFI PC hardware with SB on - USB stick on Apple hardware UEFI 2010 Macbook Air and 2012 Macbook Pro - Media test works on all of the above I have not tested it on CD or DVD physical media. I have a stack of blank discs but apparently have unplugged all my drives to use their SATA ports for SSDs :) Brian -- Brian C. Lane (PST8PDT) - weldr.io - lorax - parted - pykickstart

12 44

RHEL moving to issues.redhat.com only long term
by Josh Boyer 18 May '22

18 May '22

Hi Fedora, CentOS, and EPEL Communities! As part of our continued 3 year major Red Hat Enterprise Linux release cadence, RHEL 9 development is starting to wrap up with the spring 2022 release coming soon. That means planning for the next release will start in earnest in the very near future. As some of you may know, Red Hat has been using both Bugzilla and Jira via issues.redhat.com for RHEL development for several years. Our intention is to move to using issues.redhat.com only for the major RHEL releases after RHEL 9. What does this mean for Fedora and CentOS? This discussion is in part to figure that out. Based on some very brief analysis, the following should hold: - RHEL customers should continue to file support cases through the Red Hat Customer portal, which will remain consistent regardless of the backend tooling used. - There is no imminent retirement of the Red Hat Bugzilla instance being planned at this time. RHEL 7, 8, and 9 will continue to use bugzilla in some form and RHEL 9 has a very long lifecycle. - Fedora Linux and EPEL have their own Bugzilla product families and are not directly impacted in their own workflows by the choice to use only issues.redhat.com for RHEL. - There will be impacts on existing documentation that provide guidance on requesting things from RHEL in various places like EPEL. We will be happy to help adjust these. - CentOS Stream contribution and bug reporting workflows will be adjusted to use issues.redhat.com instead of bugzilla in the relevant places. This should apply to all versions of CentOS Stream for a unified contributor workflow. This will happen gradually as we discover the best workflow to use. If there are other impacts that you can think of, please raise them on this thread. We’d like to ensure we’re covering as much as possible as this rolls out. josh

19 32

Uninitialized variables and F37
by Steve Grubb 16 May '22

16 May '22

Hello, This is a continuation of the discussion from F36 Change: GNU Toolchain Update. Uninitialized variables are a big problem. They can be sources of information exposure if parts of a buffer are not initialized. They can also cause unexpected execution paths if the attacker can groom the memory to a value of their choosing. If the variable is a pointer to heap, this can cause free to corrupt memory under certain circumstances. If the uninitialized memory is part of user input, this can lead to improper input validation. This is not hypothetical. All of these come from a paper doing an emprical study of android flaws. [1] The data used in the paper is here. [2] Part of the problem is that compilers and static analysis tools can't always find them. I created a test program that has 8 uses of unintialized variables. Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2 or 3 - but does so much complaining you'd think it found all. Valgrind finds 2. Flexelint, a commercial linter, finds 1. Since tools can't always find them, the only option we have right now is force initialization to something the attacker cannot control. Kees Cook started a discussion on the llvm developers mail list a while back. He makes a very clear argument. I would be repeating his points, so please read the original discussion here (also read the replies): https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html He talks about -ftrivial-auto-var-init=zero being used for production builds and -ftrivial-auto-var-init=<pattern> being used for debug builds. The use is not just the kernel. Consider a server that returns data across the network to a client. It could possibly leak crypto keys or passwords if the returned data structure has uninitialized memory. For more background, the creator of this technology for LLVM presented a talk about this feature at a past LLVM developer conference: https://www.youtube.com/watch?v=I-XUHPimq3o He said this would have prevented over 900 fixed CVE's in Chrome and 12% of all Android CVE's. From deep inside the LLVM thread above, comes this nugget: --- To add in, we (Microsoft) currently use zero initialization technology in Visual Studio in a large amount of production code we ship to customers (all kernel components, a number of user-mode components). This code is both C and C++. We already have had multiple vulnerabilities killed because we shipped this technology in production. We received bug reports with repros that worked on older versions of Windows without the mitigation and new versions of Windows that do have it. The new versions don't repro, the old ones do. --- Microsoft is also digging in to uninitialized variables. They have a lengthy blog post that talks about extending this to heap memory. [3] I think this would be an important step forward to turn this on across all compilations. We could wipe out an entire class of bugs in one fell swoop. But then, what about heap allocations? Calloc has existed for a long time. It might be worthwhile to have a CFLAG that can tell glibc (or other allocators) to substitute something like calloc for malloc. Cheers, -Steve [1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf [2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/ MSR2017/vulnerabilitiesList.html [3] - https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-poo…

17 39

The future of FMN (Fedora Messaging Notifications)
by Aurelien Bompard 16 May '22

16 May '22

Hey folks! We're having a look at FMN these days, and we're trying to design its replacement in our Fedora Messaging enabled world. The current FMN has the following shortcomings: - too slow at runtime - slow at startup time (a couple of hours to startup…) - complex UI We think that this all comes from the same root cause: FMN is too flexible. It's trying to be everyone's procmail, and as a result the UI is complex and performance is hindered. Also, in the past years we've adopted quite a few external services (Discourse, Gitlab, etc) which come with their own notification systems, so the needs of FMN users may have changed, and FMN can no longer be the one-stop-shop of notifications it aimed to be. So we're planning to rewrite it as a much more simple notification system, with a few pre-defined things you could subscribe to, clearly presented in the UI but with less bells and whistles, and for that we're gathering your requirements. What do you want from Fedora's notifications? We have identified the following use cases: - I want to be notified of what happens on my artifacts (packages, containers, modules, flatpaks) - I want to be notified of what happens on any artifact by entering its type and its name - I want to be notified of events referring to my username - I want to be able to follow someone (for example, my mentee) - I want to be able to block or allow notifications from a particular application (koji, bodhi, dist-git, etc) - I want to my notifications to be sent via email and/or IRC Are there other use cases that would make your contributor's life easier? We're not committing to implementing everything that will be suggested here, since we want to keep the app as simple as we can, but we're very interested in your use cases. And if you want to do something very complex with notifications, we can also help you write a Fedora Messaging callback that will give you the full power of the message bus :-) Thanks for your help! Aurélien

10 16

F37 Change: Deprecate Legacy BIOS (System-Wide Change proposal)
by Ben Cotton 10 May '22

10 May '22

https://fedoraproject.org/wiki/Changes/DeprecateLegacyBIOS == Summary == Make UEFI a hardware requirement for new Fedora installations on platforms that support it (x86_64). Legacy BIOS support is not removed, but new non-UEFI installation is not supported on those platforms. This is a first step toward eventually removing legacy BIOS support entirely. == Owner == * Name: [[User:rharwood| Robbie Harwood]], [[User:jkonecny| Jiří Konečný]], [[User:bcl| Brian C. Lane]] * Email: rharwood(a)redhat.com == Detailed Description == UEFI is defined by a versioned standard that can be tested and certified against. By contrast, every legacy BIOS is unique. Legacy BIOS is widely considered deprecated (Intel, AMD, Microsoft, Apple) and on its way out. As it ages, maintainability has decreased, and the status quo of maintaining both stacks in perpetuity is not viable for those currently doing that work. It is inevitable that legacy BIOS will be removed in a future release. To ease this transition as best we can, there will be a period (of at least one Fedora release) where it will be possible to boot using the legacy BIOS codepaths, but new installations will not be possible. While it would be easier for us to cut support off today, our hope is that this compromise position will make for a smoother transition. Additional support with issues during the transition would be appreciated. While this will eventually reduce workload for boot/installation components (grub2 reduces surface area, syslinux goes away entirely, anaconda reduces surface area), the reduction in support burden extends much further into the stack - for instance, VESA support can be removed from the distro. Fedora already requires a 2GHz dual core CPU at minimum (and therefore mandates that machines must have been made after 2006). Like the already accepted Fedora 37 change to retire ARMv7 support, the hardware targeted tends to be rather underpowered by today’s standards, and the world has moved on from it. Intel stopped shipping the last vestiges of BIOS support in 2020 (as have other vendors, and Apple and Microsoft), so this is clearly the way things are heading - and therefore aligns with Fedora’s “First” objective. == Feedback == Dropping legacy BIOS was previously discussed (but not proposed) in 2020: https://lists.fedoraproject.org/archives/list/devel%40lists.fedoraproject.o… Important, relevant points from that thread (yes, I reread the entire thread) that have informed this change: * Some machines are BIOS-only. This change does not prevent their use yet, but they are effectively deprecated. grub2 (our default bootloader) is already capable of both BIOS and UEFI booting. * Drawing a clear year cutoff, let alone a detailed list of hardware this change affects, is basically impossible. This is unfortunate but unlikely to ever change. * There is no migration story from Legacy BIOS to UEFI - repartitioning effectively mandates a reinstall. As a result, we don’t drop support for existing Legacy BIOS systems yet, just new installations. * There is no way to deprecate hardware without causing some amount of friction. * While at the time AWS did not support UEFI booting, that is no longer the case and they support UEFI today. == Benefit to Fedora == UEFI is required for many desirable features, including applying firmware updates (fwupd) and supporting SecureBoot. As a standalone change, it reduces support burden on everything involved in installing Fedora, since there becomes only one way to do it per platform. Finally, it simplifies our install/live media, since it too only has to boot one way per arch. Freedom Friends Features First - this is that last one. == Scope == * Proposal owners: ** bootloaders: No change (existing Legacy BIOS installations still supported). ** anaconda: No change (there could be only optional cleanups in the code). However, it needs to be verified. ** Lorax: Code has already been written: https://github.com/weldr/lorax/pull/1205 * Other developers: ** libvirt: UEFI works today, but is not the default. UEFI-only installation is needed for Windows 11, and per conversations, libvirt is prepared for this change. ** Virtualbox: UEFI Fedora installs are working and per virtualbox team, UEFI will be/is the default in 7.0+. ** The Hardware Overview page should be updated to mention the UEFI requirement: https://docs.fedoraproject.org/en-US/fedora/rawhide/release-notes/welcome/H… * Release engineering: [https://pagure.io/releng/issue/10738 #Releng issue 10738] * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == Systems currently using Legacy BIOS for booting on x86_64 will continue to do so. However, this modifies the baseline Fedora requirements and some hardware will no longer be supported for new installations. == How To Test == UEFI installation has been supported for quite a while already, so additional testing there should not be required. == User Experience == Installs will continue to work on UEFI, and will not work on Legacy BIOS. Our install media is already UEFI-capable. == Dependencies == None == Contingency Plan == Leave things as they are. Code continues to rot. Community assistance is required to continue the status quo. Current owners plan to orphan some packages regardless of whether the proposal is accepted. Another fallback option could be, if a Legacy BIOS SIG organizes, to donate the relevant packages there and provide some initial mentoring. Longer term, packages that cannot be wholly donated could be split, though it is unclear whether the synchronization thereby required would reduce the work for anyone. * Contingency mechanism: Delay until next release. * Contingency deadline: Beta freeze * Blocks release? No == Documentation == See release notes. == Release Notes == Fedora 37 marks legacy BIOS installation as deprecated on x86_64 in favor of UEFI. While systems already using Legacy BIOS to boot are still supported, new legacy BIOS installations on these architectures are no longer possible. Legacy BIOS support will be removed entirely in a future Fedora. (Additionally, the Hardware Overview page should be updated to mention the UEFI requirement.) -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

68 316

← Newer
1
2
3
4
5
6
7
...
37
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel April 2022