devel-announce April 2022

devel-announce@lists.fedoraproject.org

3 participants
17 discussions

Start a nNew thread

F37 Proposal: Node.js 18.x by default (System-Wide Change proposal)
by Ben Cotton 29 Apr '22

29 Apr '22

1 0

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

29 Apr '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

1 0

Fedora Linux 36 Final is NO-GO
by Ben Cotton 28 Apr '22

28 Apr '22

Due to outstanding blocker bugs[1], we F36 Final release candidate 3 was declared NO-GO. The next Fedora Linux 36 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 5 May in #fedora-meeting. We will aim for the "target date #3" milestone of 10 May. The release schedule[3] has been updated accordingly. Minutes[4] and logs[5] of the Go/No-Go meeting are available on Meetbot. [1] https://qa.fedoraproject.org/blockerbugs/milestone/36/final/buglist [2] https://calendar.fedoraproject.org/meeting/10242/ [3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html [4] https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no… [5] https://meetbot.fedoraproject.org/fedora-meeting/2022-04-28/f36-final-go_no… -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

REMINDER: Fedora Linux 36 Final Go/No-Go meeting tomorrow
by Ben Cotton 27 Apr '22

27 Apr '22

Hi everyone, The Fedora Linux 36 Final Go/No-Go meeting[1] is scheduled for Thursday 28 April at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F36 Final for the 3 May target date #2[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10242 [2] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 25 Apr '22

25 Apr '22

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/<pkgname> Full report available at: https://churchyard.fedorapeople.org/orphans-2022-04-25.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change ================================================================================ erlang-riak_api bowlofeggs, erlang-maint-sig, 1 weeks ago orphan erlang-riak_core bowlofeggs, erlang-maint-sig, 1 weeks ago orphan forbidden-apis jvanek, orphan 1 weeks ago gnome-shell-extension-material- atim, orphan 2 weeks ago shell golang-github-astaxie-beego go-sig, orphan 2 weeks ago golang-github-influxdata- go-sig, orphan 1 weeks ago influxdb hd-idle atim, orphan 3 weeks ago jsoup mizdebsk, orphan 0 weeks ago libcxl orphan 1 weeks ago mcrcon orphan 3 weeks ago mustache-d orphan 1 weeks ago python-django-auth-ldap orphan 0 weeks ago python-readthedocs-sphinx-ext jjames, orphan, python-sig 0 weeks ago qt5-qtcanvas3d kde-sig, orphan 5 weeks ago qt5-qtenginio kde-sig, lupinix, orphan 5 weeks ago quake2 orphan 1 weeks ago rubygem-request_store orphan 3 weeks ago rust-ab_glyph orphan, rust-sig 0 weeks ago rust-alsa orphan, rust-sig 0 weeks ago rust-alsa-sys orphan, rust-sig 0 weeks ago rust-bitreader orphan, rust-sig 0 weeks ago rust-build-env orphan, rust-sig 0 weeks ago rust-cgmath orphan, rust-sig 0 weeks ago rust-chlorine orphan, rust-sig 0 weeks ago rust-claxon orphan, rust-sig 0 weeks ago rust-cloudflare-zlib orphan, rust-sig 0 weeks ago rust-cloudflare-zlib-sys orphan, rust-sig 0 weeks ago rust-cpal orphan, rust-sig 0 weeks ago rust-cstr-argument orphan, rust-sig 0 weeks ago rust-diffus-derive orphan, rust-sig 5 weeks ago rust-fallible_collections orphan, rust-sig 0 weeks ago rust-fontconfig-parser orphan, rust-sig 0 weeks ago rust-genmesh orphan, rust-sig 0 weeks ago rust-glyph_brush_layout orphan, rust-sig 0 weeks ago rust-hound orphan, rust-sig 0 weeks ago rust-image-roll orphan, rust-sig 0 weeks ago rust-imgui orphan, rust-sig 0 weeks ago rust-imgui-sys orphan, rust-sig 0 weeks ago rust-lewton orphan, rust-sig 0 weeks ago rust-libdeflate-sys orphan, rust-sig 0 weeks ago rust-libdeflater orphan, rust-sig 0 weeks ago rust-libsystemd-sys orphan, rust-sig 0 weeks ago rust-libwebp-sys2 orphan, rust-sig 0 weeks ago rust-minimp3 orphan, rust-sig 0 weeks ago rust-minimp3-sys orphan, rust-sig 0 weeks ago rust-newsblur_api orphan, rust-sig 5 weeks ago rust-ogg orphan, rust-sig 0 weeks ago rust-opml orphan, rust-sig 5 weeks ago rust-pam-client orphan, rust-sig 0 weeks ago rust-piston orphan 0 weeks ago rust-piston-float orphan, rust-sig 0 weeks ago rust-piston- orphan, rust-sig 0 weeks ago graphics_api_version rust-piston-viewport orphan, rust-sig 0 weeks ago rust-pistoncore-event_loop orphan 0 weeks ago rust-pistoncore-input orphan, rust-sig 0 weeks ago rust-rental-impl orphan, rust-sig 0 weeks ago rust-ringbuf orphan, rust-sig 0 weeks ago rust-systemd orphan, rust-sig 0 weeks ago rust-utf8-cstr orphan, rust-sig 0 weeks ago rust-vcpkg orphan, rust-sig 0 weeks ago rust-zopfli orphan, rust-sig 0 weeks ago yecht orphan 6 weeks ago The following packages require above mentioned packages: Report too long, see the full version at https://churchyard.fedorapeople.org/orphans-2022-04-25.txt See dependency chains of your packages at https://packager-dashboard.fedoraproject.org/ See all orphaned packages at https://packager-dashboard.fedoraproject.org/orphan Affected (co)maintainers (either directly or via packages' dependencies): almac: jsoup amigadave: python-readthedocs-sphinx-ext ankursinha: python-readthedocs-sphinx-ext atim: hd-idle, gnome-shell-extension-material-shell bowlofeggs: erlang-riak_core, erlang-riak_api cdorney: jsoup cfu: jsoup churchyard: python-readthedocs-sphinx-ext cicku: python-readthedocs-sphinx-ext cstratak: python-readthedocs-sphinx-ext dbhole: jsoup dchen: jsoup deamn: jsoup didiksupriadi41: jsoup dmsimard: python-readthedocs-sphinx-ext echevemaster: python-readthedocs-sphinx-ext eclipse-sig: jsoup ellert: jsoup epel-packagers-sig: python-readthedocs-sphinx-ext erlang-maint-sig: erlang-riak_core, erlang-riak_api go-sig: golang-github-influxdata-influxdb, golang-github-astaxie-beego guidograzioli: jsoup hhorak: jsoup ignatenkobrain: rust-opml, rust-newsblur_api infra-sig: python-readthedocs-sphinx-ext jcapik: jsoup jerboaa: jsoup jhuttana: jsoup jjames: jsoup, python-readthedocs-sphinx-ext jjelen: jsoup jmagne: jsoup jorti: python-readthedocs-sphinx-ext jvanek: forbidden-apis kde-sig: qt5-qtcanvas3d, qt5-qtenginio ke4qqq: jsoup kni: jsoup korkeala: jsoup ksurma: python-readthedocs-sphinx-ext kubo: python-readthedocs-sphinx-ext lbalhar: python-readthedocs-sphinx-ext lupinix: qt5-qtenginio mbooth: jsoup mharmsen: jsoup mhayden: python-readthedocs-sphinx-ext mikelo2: python-readthedocs-sphinx-ext mizdebsk: jsoup mjakubicek: jsoup mkulik: jsoup mrunge: python-readthedocs-sphinx-ext msimacek: jsoup neuro-sig: python-readthedocs-sphinx-ext ngompa: python-readthedocs-sphinx-ext odubaj: jsoup orion: python-readthedocs-sphinx-ext pingou: jsoup pjp: python-readthedocs-sphinx-ext pnemade: python-readthedocs-sphinx-ext python-sig: python-readthedocs-sphinx-ext raphgro: python-readthedocs-sphinx-ext rust-sig: rust-chlorine, rust-diffus-derive, rust-systemd, rust-zopfli, rust-imgui, rust-minimp3-sys, rust-minimp3, rust-piston-viewport, rust-piston-graphics_api_version, rust-imgui-sys, rust-libdeflater, rust-pam-client, rust-genmesh, rust-alsa-sys, rust-hound, rust-libwebp-sys2, rust-rental-impl, rust-bitreader, rust-ringbuf, rust-cloudflare-zlib, rust-lewton, rust-fontconfig-parser, rust-cgmath, rust-utf8-cstr, rust-claxon, rust-cpal, rust-libdeflate-sys, rust-cstr-argument, rust-libsystemd-sys, rust-newsblur_api, rust-cloudflare-zlib-sys, rust-build-env, rust-alsa, rust-piston-float, rust-ab_glyph, rust-opml, rust-pistoncore-input, rust-ogg, rust-vcpkg, rust-glyph_brush_layout, rust-image-roll, rust-fallible_collections salimma: python-readthedocs-sphinx-ext sasiddiq: jsoup scorreia: rust-vcpkg smani: python-readthedocs-sphinx-ext smilner: python-readthedocs-sphinx-ext spot: jsoup suve: python-readthedocs-sphinx-ext tagoh: python-readthedocs-sphinx-ext thrnciar: python-readthedocs-sphinx-ext ueno: rust-vcpkg walters: jsoup yyang: jsoup zmiklank: jsoup -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2022-04-25 17:08:08 UTC -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Fedora Linux 36 Final is NO-GO
by Ben Cotton 20 Apr '22

20 Apr '22

Due to outstanding blocker bugs[1], we do not have an F36 Final release candidate. As a result, F36 Final is NO-GO for target date #1 and tomorrow's Go/No-Go meeting is cancelled. The next Fedora Linux 36 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 28 April in #fedora-meeting. We will aim for the "target date #2" milestone of 3 May. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/36/final/buglist [2] https://calendar.fedoraproject.org/meeting/10242/ [3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

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

18 Apr '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

1 0

Fedora Linux 36 Final is NO-GO
by Ben Cotton 13 Apr '22

13 Apr '22

Due to outstanding blocker bugs[1], we do not have an F36 Final release candidate. As a result, F36 Final is NO-GO for the early release target and tomorrow's Go/No-Go meeting is cancelled. The next Fedora Linux 36 Final Go/No-Go meeting[2] will be held at 1700 UTC on Thursday 21 April in #fedora-meeting. We will aim for the "target date #1" milestone of 26 April. The release schedule[3] has been updated accordingly. [1] https://qa.fedoraproject.org/blockerbugs/milestone/36/final/buglist [2] https://calendar.fedoraproject.org/meeting/10242/ [3] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 Change: Haskell GHC 9.0 & Stackage LTS 19 (Self-Contained Change proposal)
by Ben Cotton 12 Apr '22

12 Apr '22

https://fedoraproject.org/wiki/Changes/Haskell_GHC_9.0_%26_Stackage_19 == Summary == The GHC Haskell compiler will be updated from major version 8.10 to 9.0, and Haskell packages will be updated from Stackage LTS 18 to LTS 19 versions. == Owner == * Name: [[User:Petersen|Jens Petersen]] * Email: petersen(a)redhat.com * Name: [[Haskell_SIG|Haskell SIG]] * Email: haskell(a)lists.fedoraproject.org == Detailed Description == For Fedora 37, the GHC Haskell compiler will be updated from version 8.10.5 to the latest stable 9.0.2 release (rebasing from the ghc9.0 package). Along with this, Haskell packages in [https://www.stackage.org Stackage] (the stable Haskell source package distribution) will be updated from the versions in LTS 18 to latest LTS 19 release. Haskell packages not in Stackage will be updated to the latest appropriate version in the upstream [https://hackage.haskell.org Hackage] package repository. == Benefit to Fedora == Fedora users will have the latest stable Haskell compiler release, package tools, and current Haskell packages from Stackage LTS. GHC 9.0 is first major release of the GHC 9 series and features performance improvements, new language extension features (in particular Linear types support), and bugfixes (see the release notes linked in the Documentation section for more details). == Scope == * Proposal owners: ** update ghc8.10 is build against itself ** rebase ghc to 9.0.2 ** update ghc-rpm-macros to the final version for F37 ** refresh packagings with the latest cabal-rpm release ** update packages to latest [https://www.stackage.org/lts-19 Stackage LTS 19] versions using cabal-rpm ** build all the packages in a Koji sidetag repo in dependency order using fbrnch ** push the sidetag through Bodhi to Rawhide before the mass rebuild * Other developers: no actions should be needed <!-- * Release engineering: * 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 == Any dropped packages will have obsoletes added. Otherwise there should not be any direct upgrade impact. Users' Haskell projects will get built with ghc-9.0 when they next build them and might need some minor code tweaks. == How To Test == * install ghc and cabal-install * install pandoc, ShellCheck, ghcid, git-annex, hadolint, stack, xmonad * install ghc-*-devel or ghc-*-prof or ghc-*-doc * cabal-rpm builddep <favouritepackage>; cabal install <favouritepackage> * test upgrades of F36 Haskell packages to F37 == User Experience == Users will have the most recent stable major version of `ghc` and Haskell libraries and tools available to them. This makes it easier to build the latest versions of Haskell projects. In particular `cabal-install` will also be updated from 3.2 to 3.4. == Dependencies == == Contingency Plan == * Contingency mechanism: Change owner will drop the new builds and revert back to the versions in F36. * Contingency deadline: Beta Freeze * Blocks release? N/A (not a System Wide Change) == Documentation == * https://www.haskell.org/ghc/blog/20210204-ghc-9.0.1-released.html * https://downloads.haskell.org/~ghc/9.0.2/docs/html/users_guide/9.0.1-notes.… * https://www.haskell.org/ghc/blog/20211225-ghc-9.0.2-released.html * https://downloads.haskell.org/~ghc/9.0.2/docs/html/users_guide/9.0.2-notes.… == Release Notes == The Haskell GHC compiler has been updated from 8.10.5 to 9.0.2 with many improvements. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F38 Change: Major upgrade of Microdnf (Self-Contained Change proposal)
by Ben Cotton 12 Apr '22

12 Apr '22

https://fedoraproject.org/wiki/Changes/MajorUpgradeOfMicrodnf == Summary == A major upgrade of Microdnf is the first step in the evolution of package management in Fedora. The new microdnf has ambitions to provide all major features of DNF without losing its minimal footprint. == Owner == * Name: [[User:jmracek| Jaroslav Mracek]] * Email: jmracek(a)redhat.com == Detailed Description == The new major Microdnf will provide huge improvements and in some cases better behavior then DNF. In the future, the new Microdnf will replace DNF. The new Microdnf will be accompanied by a new library (`libdnf5`) and a new DNF Daemon. === MICRODNF features === * Improved user experience ** Improved progress bars ** Improved transaction table ** Transaction progress reports including scriptlets reports ** Support of local rpm for transaction operation ** Great bash completion (better then DNF has) === LIBDNF5 features === * Fully integrated Modularity in LIBDNF workflows ** Modularity is currently supported in DNF and LIBDNF, but it is not fully integrated due to limitations in compatibility with other tools (PackageKit) ** Fully integrated Modularity requires changes in library workflow * Unified user interface ** DNF/YUM was developed for decades with the impact of multiple styles and naming conventions (options, configuration options, commands) * Plugins ** DNF plugins are not applicable for PackageKit and Microdnf (e.g. versionlock, subscription-manager), therefore PackageKit behaves differently to DNF * New plugins (C++, Python) will be available for all users ** Unified behavior ** Removal of functional duplicates *** Decrease maintenance cost * Shared configurations ** In DNF4 the configuration is only partially honored by PackageKit and Microdnf * New Daemon ** The new daemon can provide an alternative to PackageKit for RPMs (only one backend of PackageKit) if it will be integrated into the Desktop * Additional improvements ** Reports in structure (API) *** DNF reports a lot of important information only in logs * Shared cache and improved cache handling (optional, not available in Fedora 38) ** Microdnf, DNF4, and PackageKit use cached repositories on a different location with different cache structure * Performance improvement ** Loading of repositories ** Advisory operation ** RPM query *** Name filters with a case-insensitive search ** Smart sharing of metadata between dnf, microdnf, daemon (optional, not available in Fedora 38) *** Reduce disk and downloads requirements * Relocation of internal databases into `/usr` ** Make rollback more easy === Downsides === * Relocation of internal databases and different structure of internal databases ** The transaction performed by the new MICRODNF will be not visible by DNF ** The transaction performed by DNF or PackageKit will be not visible by the new MICRODNF ** Packages installed by another packager will be handled as userinstalled *** Consequence => The removal of a package will not trigger removal of unused dependencies * Compatibility ** To improve user experience and to unify dnf/microdnf behavior we were unable to keep 100% compatibility with formal Microdnf in command-line and in behavior == Benefit to Fedora == The new MICRODNF significantly improves the user experience and in the future it will provide all important features of DNF. It will also keep all advantages of the original MICRODNF, like minimal size required by containers. The presence of MICRODNF, LIBDNF5, and DNFDAEMON in the distribution will also allow for a smooth transition of components using `dnf`, `python3-dnf`, `python3-hawkey`, `libdnf`, `dnfdragora`, and `python3-dnfdaemon` to a new library. * Improved progress bars * Improved transaction table * Transaction progress reports including scriptlets reports * Support of local rpm for transaction operation * Great bash completion (better then DNF has) * `builddep` command without Python on the system == Scope == * Proposal owners: The new Microdnf is still in the development and some of the features or options are not yet available. We still have to finish the implementation of Modularity, storing internal data related to History and System State, and also documentation and man pages. The new Microdnf can be tested from repository with upstream nightly builds - https://copr.fedorainfracloud.org/coprs/rpmsoftwaremanagement/dnf5-unstable/. The project's github repository is here - https://github.com/rpm-software-management/libdnf/tree/dnf-5-devel * Other developers: * Release engineering: * 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 == == User Experience == * Improved progress bars * Improved transaction table * Transaction progress reports including scriptlets reports * Support of local rpm for transaction operation * Great bash completion (better then DNF has) * New commands and options that are only available with `DNF` == 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), Yes/No == Documentation == N/A (not a System Wide Change) == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Orphaned packages looking for new maintainers
by Miro Hrončok 12 Apr '22

12 Apr '22

The following packages are orphaned and will be retired when they are orphaned for six weeks, unless someone adopts them. If you know for sure that the package should be retired, please do so now with a proper reason: https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life Note: If you received this mail directly you (co)maintain one of the affected packages or a package that depends on one. Please adopt the affected package or retire your depending package to avoid broken dependencies, otherwise your package will fail to install and/or build when the affected package gets retired. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/<pkgname> Full report available at: https://churchyard.fedorapeople.org/orphans-2022-04-12.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager-dashboard.fedoraproject.org/ For all orphaned packages, see https://packager-dashboard.fedoraproject.org/orphan Package (co)maintainers Status Change =============================================================================== beanstalk-client orphan 5 weeks ago gnome-shell-extension-material-shell atim, orphan 0 weeks ago golang-github-astaxie-beego go-sig, orphan 0 weeks ago golang-github-influxdata-influxdb go-sig, orphan 2 weeks ago golang-github-mdlayher-wifi go-sig, orphan 4 weeks ago hd-idle atim, orphan 1 weeks ago lua-ldap orphan 5 weeks ago mcrcon orphan 1 weeks ago python-aiohttp-cors orphan, python-sig 5 weeks ago python-aiohttp-negotiate orphan 5 weeks ago python-fastimport orphan 5 weeks ago python-lrparsing orphan 5 weeks ago python-ofxparse orphan 5 weeks ago python-plyvel orphan 5 weeks ago python-pystalk orphan 5 weeks ago qcommandline orphan 5 weeks ago qt5-qtcanvas3d kde-sig, orphan 3 weeks ago qt5-qtenginio kde-sig, lupinix, orphan 3 weeks ago rubygem-request_store orphan 1 weeks ago rust-diffus orphan, rust-sig 3 weeks ago rust-diffus-derive orphan, rust-sig 3 weeks ago rust-newsblur_api orphan, rust-sig 3 weeks ago rust-opml orphan, rust-sig 3 weeks ago rust-xmltree orphan, rust-sig 3 weeks ago yecht orphan 4 weeks ago The following packages require above mentioned packages: Depending on: golang-github-mdlayher-wifi (1), status change: 2022-03-11 (4 weeks ago) golang-github-prometheus-node-exporter (maintained by: eclipseo, go-sig) golang-github-prometheus-node-exporter-1.3.1-6.fc36.src requires golang(github.com/mdlayher/wifi) = 0-0.12.20200729git84f0b94.fc36 golang-github-prometheus-node-exporter-devel-1.3.1-6.fc36.noarch requires golang(github.com/mdlayher/wifi) = 0-0.12.20200729git84f0b94.fc36 Depending on: python-aiohttp-cors (1), status change: 2022-03-02 (5 weeks ago) gns3-server (maintained by: kwizart, nucleo) gns3-server-2.2.31-2.fc37.noarch requires python3.10dist(aiohttp-cors) = 0.7 Depending on: rust-diffus (1), status change: 2022-03-20 (3 weeks ago) newsflash (maintained by: ignatenkobrain, rust-sig) newsflash-1.5.1-2.fc36.src requires crate(diffus/default) = 0.10.0, crate(diffus/derive) = 0.10.0 Depending on: rust-diffus-derive (2), status change: 2022-03-20 (3 weeks ago) rust-diffus (maintained by: orphan, rust-sig) rust-diffus+derive-devel-0.10.0-2.fc36.noarch requires crate(diffus-derive/default) = 0.10.0 rust-diffus+diffus-derive-devel-0.10.0-2.fc36.noarch requires crate(diffus-derive/default) = 0.10.0 rust-diffus+serialize-impl-devel-0.10.0-2.fc36.noarch requires crate(diffus-derive/serialize-impl) = 0.10.0 newsflash (maintained by: ignatenkobrain, rust-sig) newsflash-1.5.1-2.fc36.src requires crate(diffus/default) = 0.10.0, crate(diffus/derive) = 0.10.0 Depending on: rust-newsblur_api (2), status change: 2022-03-15 (3 weeks ago) rust-news-flash (maintained by: ignatenkobrain, rust-sig) rust-news-flash-1.2.1-6.fc36.src requires crate(newsblur_api/default) = 0.1.2 rust-news-flash-devel-1.2.1-6.fc36.noarch requires crate(newsblur_api/default) = 0.1.2 newsflash (maintained by: ignatenkobrain, rust-sig) newsflash-1.5.1-2.fc36.src requires crate(news-flash/default) = 1.2.1 Depending on: rust-opml (2), status change: 2022-03-20 (3 weeks ago) rust-news-flash (maintained by: ignatenkobrain, rust-sig) rust-news-flash-1.2.1-6.fc36.src requires crate(opml/default) = 1.1.1 rust-news-flash-devel-1.2.1-6.fc36.noarch requires crate(opml/default) = 1.1.1 newsflash (maintained by: ignatenkobrain, rust-sig) newsflash-1.5.1-2.fc36.src requires crate(news-flash/default) = 1.2.1 Depending on: rust-xmltree (1), status change: 2022-03-20 (3 weeks ago) newsflash (maintained by: ignatenkobrain, rust-sig) newsflash-1.5.1-2.fc36.src requires crate(xmltree/default) = 0.10.3 Affected (co)maintainers (either directly or via packages' dependencies): atim: gnome-shell-extension-material-shell, hd-idle eclipseo: golang-github-mdlayher-wifi go-sig: golang-github-mdlayher-wifi, golang-github-influxdata-influxdb, golang-github-astaxie-beego ignatenkobrain: rust-diffus, rust-xmltree, rust-newsblur_api, rust-opml, rust-diffus-derive kde-sig: qt5-qtcanvas3d, qt5-qtenginio kwizart: python-aiohttp-cors lupinix: qt5-qtenginio nucleo: python-aiohttp-cors python-sig: python-aiohttp-cors rust-sig: rust-diffus, rust-xmltree, rust-newsblur_api, rust-opml, rust-diffus-derive -- The script creating this output is run and developed by Fedora Release Engineering. Please report issues at its pagure instance: https://pagure.io/releng/ The sources of this script can be found at: https://pagure.io/releng/blob/main/f/scripts/find_unblocked_orphans.py Report finished at 2022-04-12 07:15:34 UTC

1 0

F37 Change: Legacy Xorg Driver Removal (System-Wide Change proposal)
by Ben Cotton 07 Apr '22

07 Apr '22

https://fedoraproject.org/wiki/Changes/LegacyXorgDriverRemoval == Summary == This change will remove the `xorg-x11-drv-vesa` and `xorg-x11-drv-fbdev` driver packages, and associated support code from the `xorg-x11-server-Xorg` package. == Owner == * Name: [[User:ajax|Adam Jackson]] * Email: ajax(a)redhat.com == Detailed Description == Fedora's primary desktop environments are moving away from being X11 sessions, to being Wayland servers in their own right. This transition is incomplete, and the Xorg server is still potentially used in a variety of "fallback" situations. In particular the `vesa` and `fbdev` drivers can find themselves pressed into use when accelerated graphics is unavailable. Both of these drivers are somewhat deprecated upstream, and the code to reach them is increasingly fragile as it gets exercised less and less. This change will identify the remaining configurations that can reach these drivers, establish an alternative for display support for each configuration, and then remove the drivers and their support code in xserver. == Feedback == None yet. == Benefit to Fedora == * Verified modern supported paths for cases currently handled by vesa/fbdev * Simpler support/testing matrix for QE * One less reason to need Xorg installed at all == Scope == * Proposal owners: ajax needs to audit hardware support matrix for cases that can hit these drivers, and the rest of the OS for places that can configure them. * Other developers: Maintainers of other affected components may need to incorporate some changes, and may wish to look for additional support code that can be dropped. * Release engineering: This is mostly ensuring that the two driver packages are indeed dropped from the compose, etc. * Policies and guidelines: N/A (not needed for this Change) Although this is a system-wide change I don't think there's any real policy impact. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: Yes, we'd be arguably the First to try this. == Upgrade/compatibility impact == For an upgraded system to notice this change, it would need to be already using one of these drivers. For cases we can identify where this would happen without explicit configuration, we will ensure the display is enabled by some other path or documented as no longer supported. However, for cases where the driver is set explicitly in `xorg.conf`, there is no obviously correct remedy that we could do automatically, and the user will need to fix their X configuration manually. == How To Test == This should fall out naturally from the normal release testing process, but we'll expand the details here as the various configurations are tested and fixed. == User Experience == This change should be largely invisible, but there will likely be observable changes (for instance, if you end up using a Wayland session, `$WAYLAND_DISPLAY` will likely no longer be empty). These will be documented here as we fix the individual cases. == Dependencies == The kernel may need changes to add more drivers for more situations. The installer and other system-wide configuration tools should be audited to ensure they don't emit cases that can force vesa/fbdev. The major desktop environments may need to be fixed to handle more cases, and may wish to drop code to support the old cases. == Contingency Plan == * Contingency mechanism: ajax reverts the changes. * Contingency deadline: Beta freeze seems fine. * Blocks release? No. Partial completion is possible. == Documentation == Just this page so far. == Release Notes == None yet. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

F37 Change: RPM 4.18 (System-Wide Change proposal)
by Ben Cotton 07 Apr '22

07 Apr '22

https://fedoraproject.org/wiki/Changes/RPM-4.18 == Summary == Update RPM to the [https://rpm.org/wiki/Releases/4.18.0 4.18] release. == Owner == * Name: [[User:pmatilai|Panu Matilainen]] * Email: pmatilai(a)redhat.com == Detailed Description == RPM 4.18 contains various improvements over previous versions, but in particular this release addresses a whole class of symlink handling related security issues, some with CVE's, from 2021. Other notable improvements include * A more intuitive conditional builds macro `%bcond` * A more robust and secure `--restore` functionality * Long-standing `%patch` quirks fixed * Weak dependencies accept qualifiers like `meta` and `pre` now * New interactive shell for working with macros (`rpmspec --shell`) and embedded Lua (`rpmlua`) * New `%conf` spec section for build configuration * New `rpmuncompress` cli tool simplifies unpacking multiple sources * Numerous macro improvements and fixes * Numerous OpenPGP parser correctness and security fixes == Benefit to Fedora == The main benefits of this release are increased security and packaging experience improvements, see above for details. == Scope == * Proposal owners: ** Rebase RPM ** Assist with dealing with incompatibilities * Other developers: ** Test new release, report issues and bugs * Release engineering: [https://pagure.io/releng/issue/10742 #10742] * Policies and guidelines: N/A (not needed for this Change). Utilizing new rpm features is subject to packaging guidelines but othe * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A (no relation to current objectives) == Upgrade/compatibility impact == There are no noteworthy compatibility issues with this release. == How To Test == Rpm receives a thorough and constant testing via every single package build, system installs and updates. New features can be tested specifically as per their documentation. == User Experience == There are no major differences in the normal user experience. == Dependencies == * No new dependencies are introduced in this release * Other changes are known to be affected * Library soname will not change so no rebuilds are required == Contingency Plan == * Contingency mechanism: Revert back to RPM 4.17 * Contingency deadline: Beta freeze * Blocks release? No == Documentation == Work-in-progress release notes at https://rpm.org/wiki/Releases/4.18.0 and reference manual at https://github.com/rpm-software-management/rpm/blob/master/doc/manual/index… == Release Notes == https://rpm.org/wiki/Releases/4.18.0 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Fedora Linux 36 Final Go/No-Go meeting next week
by Ben Cotton 06 Apr '22

06 Apr '22

Hi everyone, The Fedora Linux 36 Final Go/No-Go meeting[1] is scheduled for Thursday 14 April at 1700 UTC in #fedora-meeting. At this time, we will determine the status of the F36 Final for the 19 April early target date[2]. For more information about the Go/No-Go meeting, see the wiki[3]. [1] https://calendar.fedoraproject.org/meeting/10237 [2] https://fedorapeople.org/groups/schedule/f-36/f-36-key-tasks.html [3] https://fedoraproject.org/wiki/Go_No_Go_Meeting -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

Bodhi 6.0: What's new
by Aurelien Bompard 06 Apr '22

06 Apr '22

Hey everyone! Bodhi 6.0 will be published in a few days, and deployed to production a couple weeks after the Fedora release. It has backwards-incompatible changes, here's what you need to know. == Authentication == Bodhi gained support for OpenID Connect (OIDC) authentication, like most of Fedora's webapps. OpenID still works but is not the default, you can access it by using `/login?method=openid` as the login URL. Version 6.0 of the Bodhi client uses only OIDC, plain OpenID support has been dropped. Version 5.7.5 of the Bodhi client, however, uses the new OpenID login URL and has been available for about a month now, you'll need at least version 5.7.5 to use the Bodhi client with the updated server. The client's API has changed, so if you have a piece of code that imports from `bodhi.client`, you'll have to update it to use the new API, and in the meantime use version 5.7.5. As a user of the `bodhi` CLI, you'll notice that the `--username` and `--password` options have disappeared. Instead the Bodhi client will ask you to open your browser to a URL to authenticate. The authentication tokens will be saved and you'll be able to use the `bodhi` CLI without authenticating afterwards (or non-interactively). == Code reorganization == The Bodhi source code has been reorganized to drop the hacks used in `setup.py` to support sub-projects. Instead, `bodhi-server`, `bodhi-client` and `bodhi-messages` are now actual Python package directories in the repo. The import path has not changed. Bodhi's Python project metadata and dependencies are now managed with Poetry <https://python-poetry.org/>. == Other changes == - Serialized `Release` objects sent in the messages don't contain the `composes` property anymore - The `koji-build-group.build.complete` messages now contain an `update` property - In the Bodhi client API, the `save_override()` method has been extended to allow setting the expiration date directly - Misc bug fixes If you have any questions, feel free to ask the Bodhi team in our matrix room: <https://matrix.to/#/#bodhi:matrix.org>. If you are importing the bodhi client code in your app/script, or using the bodhi client in an "unusual" manner, we'll help you migrate. Thanks! Aurélien Bompard

1 0

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

05 Apr '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

1 0

F37 Change: Signed RPM Contents (System-Wide Change proposal)
by Ben Cotton 01 Apr '22

01 Apr '22

https://fedoraproject.org/wiki/Changes/Signed_RPM_Contents == Summary == We want to add signatures to individual files that are part of shipped RPMs. These signatures will use the Linux IMA (Integrity Measurement Architecture) scheme, which means they can be used to enforce runtime policies to ensure execution of only trusted files. == Owner == * Name: [[User:Pbrobinson| Peter Robinson]] * Email: pbrobinson(a)gmail.com * Name: [[User:Puiterwijk| Patrick Uiterwijk]] * Email: puiterwijk(a)redhat.com == Detailed Description == During signing builds, the files in it will be signed with IMA signatures. These signatures will be made with a key that's kept by the Fedora Infrastructure team, and installed on the sign vaults. These signature can then be used with the Linux Integrity Measurement Architecture (IMA) kernel subsystem to verify files on execution based on a policy. The IMA subsystem is described on [https://sourceforge.net/p/linux-ima/wiki/Home/ the project page]. IMA allows users to extend the trust of their system to the OS and processes. It allows the users, if they so wish, to set polices to ensure their machine and their resources are used the way they intended it to be not about restricting the use for the average Fedora user. Like all security pieces IMA doesn't solve the whole security problem with a single option, it's not intended to, but that does not mean it doesn't provide additional value and tools for Fedora users to protect their systems. To quote a section of [https://lwn.net/Articles/753276/ an LWN article]: <pre> The goals of the integrity subsystem are to detect files that have been altered, either accidentally or maliciously, by comparing a measurement of the current file contents with that of a stored "good" value; it can then enforce various file integrity policies (e.g. no access or no execution). IMA is three separate pieces: measurement, which calculates a hash of file contents; appraisal, which verifies file signatures made using the measured hashes; and audit, which records hashes and other information in the audit logs. There is also the extended verification module (EVM), which targets the measurement and protection of the file metadata, though that is not included in what she would be presenting. It is important to note that IMA does not protect against attacks on objects in memory, it can only be used to thwart attacks that change files. </pre> The intention here is not to ship a default policies for users but rather have sample policies that users can modify and use themselves. The Fedora IoT Edition intends to have sample policies and documentation for a number of IoT and Edge use cases. This means that they can configure a policy based on which the kernel will determine whether to verify (or measure) files before opening them. You could for example make a policy that appraises (verifies) all files that are executed by root: `appraise uid=1000 appraise_type=imasig`. Note explicitly that we do not intend to install a default policy as part of this change, and users will need to deploy their own policy before anything is measured or appraised. This means that after this is done, users will have the option to enable a policy and have that be enforced, but there will be nothing automatic. We will, however, document various example policies people can adapt to their needs. By default, the signatures will not be deployed to the file system. That will only be done once rpm-plugin-ima is installed. After that, RPM will put the signatures on the "security.ima" extended attribute on the files. == Feedback ==  === RPM Size === One of the main concerns that have been voiced is the RPM size, both on disk (mirrors) and on an installed system. For this comparison, I have cached all the RPMs installed in a Fedora Rawhide 20210118.n.1 default Server install (server netinstall disk, and then no changes to the group selection). After creating two copies of that data, one with just resigned (to exclude rpm size difference resulting from different key lengths), and one resigned with IMA file signatures inserted, I then installed two blank VMs by using the standard virt-manager settings, changing only the name and the system type to "EFI". This is using a prime256v1 file signing key. This is the same key format supported by the Fedora signing system. ==== Binary RPMs on disk ==== Resigned: 462524 (452M) Resigned+IMA: 467812 (457M) This comes down to a 1.1% increase on size of the binary RPMs. ==== Installed size ==== On installation of two different VMs, one with the resigned RPMs, and one with the resigned+ima RPMs, the `/usr` directory size does not change at all (both are exactly 1417064 bytes). The size of the rpmdb increases from 22952 to 28416 bytes, a 20% increase. This is on an install size of 1.7GB in total, so this 5MB increase is a 0.3% size increase on the final installed system. Note that both of those VMs did not have rpm-plugins-ima installed, which means the file signatures are not put in place. When I install the rpm-plugin-ima, and run "dnf reinstall *", the `/usr` directory increases by 0.002% to 1417104. ==== RPM header size bug ==== There was a bug in rpm from when file signatures were moved over from the header into the sigheader. Details [https://pagure.io/fesco/issue/2547#comment-711253 here]. This bug is fixed in Fedora and RHEL-8. === Tie-in to Secure Boot === While using the IMA subsystem in combination with Secure Boot enables users to extend trust on the system out into the binaries executed, there is no requirement at all to use secure boot. This means that if you have Secure Boot enabled, that enables you to extend the trust, but if you don't want to use secure boot, that has no impact on the IMA subsystem. === Why in the RPM header, instead of a side-package like -debuginfo? === These signatures would need to get deployed as a filesystem extended attribute in order to be used by the IMA subsystem. While it is possible to generate the signatures as separate files in a side package, that means that RPM would then need to add code to install extended attributes based on contents of another RPM package. This would mean that the contents of an e.g. `-file-signature` subpackage won't be deployed to the file systems as normal files, but instead as xattr's on existing files. That, together with the minimal size increases of the actual RPMs, made us decide to go with the signature header approach and not implement the side-package method. === Comparison with MAC's === The IMA subsystem is orthogonal to the Mandatory Access Control systems like selinux, though it is integrated with them. Where with selinux you can limit who can read from or write to to which file, IMA will allow you to set policies that enforce file contents to be as expected (signature validated) before they can be read/executed. The integration is in the form that you can write a policy line that matches on certain selinux contexts, like for example `dont_appraise obj_type=var_log_t`, to ensure that files of `var_log_t` do not need to be verified, and `appraise obj_type=shell_exec_t` to ensure that any shell that is executed (e.g. bash) is signed with a trusted key. === Why not ... === ==== fsverity ==== As one of the fsverity maintainers has said on [https://lwn.net/Articles/842326/|LWN] IMA and FS-Verity are not mutually exclusive, but at this moment IMA has a possibility to enforce a system-wide policy instead of needing the userspace binaries to check the signature status themselves. There's currently competing proposals for upstream kernel for functionality like integration with IMA [https://www.spinics.net/lists/linux-integrity/msg21056.html this one] and [https://www.spinics.net/lists/linux-integrity/msg20947.html this one]. The proposal also requires [https://www.spinics.net/lists/linux-integrity/msg20713.html Adding PGP support to the kernel] which isn't upstream and may take some time. The [https://fedoraproject.org/wiki/Changes/FsVerityRPM FsVerity] feature also needs enhancements across Fedora including changes to koji, additions to rpm and well as filesystems that support it. It's also got limited filesystem support, for example it's not supported on XFS which is the default on the Server Edition. ==== DIGLIM ==== The Digest Lists Integrity Module (DIGLIM) isn't actually independent of this feature, it still requires digests of the files such as the ones generated here in this proposal, it just consumes them in a different method than IMA on the end system. Rather than embedding them in xattr on the filesystem as IMA does the kernel loads them into memory. Ultimately DIGLIM is complementary and has the ability to build on top of this functionality once this actually makes it upstream. ==== rpm -V ==== rpm -V will tell you whether a file matches the digest that's in the RPM Database, but that is useful if you think a file might have been accidentally changed. If an attacker has the opportunity to change a file on the file system, it is very likely they could also update the RPM binary (or the rpmdb) to make it not report the change. IMA signatures will be able to identify the file to have been changed, and importantly also enable a policy which enforces the signatures, which means that if a change was made to a file that is matched by a policy, the kernel would actively refuse loading it, instead of depending on the administrator to check its validity with a known-good rpm database and binary. == Benefit to Fedora == Having all files signed with a verifiable key means that system owners can use the kernel Integrity and Measurement Architecture (IMA) to enforce only verified files can be executed, or define other policies. Having all files signed with Fedora keys would enable integration with for example [https://keylime.dev/ Keylime], which is a CNCF project that implements remote system attestation, based on which a system may or may not get access to secrets and other consequences. This feature is wanted by the IoT Edition, for enabling both attestation and local policy verification. Many IoT users have expressed interest in this functionality and are already working to build on it. IMA doesn't solve all security issues but it provides an extra useful tool to those that wish provide higher levels of security on their devices. From other proposals such as the fsverity and DGLIM ones there is clearly a desire to be able to provide this style of extra security to Fedora users. An advantage that this proposal has, that the others do not currently provide, is that all the functionality is in place in koji, the signing infrastructure, the various packages and kernel now and doesn't depend on out of tree patches to get into various upstream projects or work on Fedora infrastructure to be scheduled. == Scope == * Proposal owners: The proposal owners will generate the keys in Infrastructure and get them deployed to the sign vaults, and enable the configuration options for this in robosignatory. Support for file signatures is already in the deployed versions of sigul and robosignatory. * Other developers: Nothing needed from other developers * Release engineering: [https://pagure.io/releng/issue/10731 #10731] A mass rebuild would be nice (as it ensures all packages are signed), but is not required to implement the change itself. * Policies and guidelines: No impact * Trademark approval: No impact * Alignment with Objectives: This aligns with the Internet of Things objective. == Upgrade/compatibility impact == For standard Fedora users there will be a very tiny increase in rpmdb size. If an advanced user was already signing their own files (for the Fedora shipped RPMs) for IMA functionality, they will just overwrite the existing signature. == How To Test == You can verify that a signature has been put in place by looking at the extended attribute by running: `getfattr -d -m security.ima /usr/bin/bash` (change `/usr/bin/bash` with the file to check). The signatures can be tested “in vitro” by running `evmctl ima_verify --key publiccert.der -v myfile.txt`. This should result in the system reporting “<filename>: verification is OK”. The full system could be tested by enrolling the Fedora IMA key to the kernel `_ima` keyring, and adding a policy that verifies (some) files to be verified against the key. (instructions to follow). == User Experience == If the user deploys an IMA policy to verify all or some files, they should be able to trust the signatures made by the Fedora build system. == Dependencies == No external package dependencies. == Contingency Plan == * Contingency mechanism: None. The development work is already complete and all the infrastructure functionality is upstream. * Contingency deadline: The signing should be turned on before a mass rebuild, and is ready to go if the change is approved. * Blocks release? No * Blocks product? N/A == Documentation == We intend to write documentation on how to use the IMA subsystem for docs.fedoraproject.org, but that is orthogonal to this feature itself. We expect to provide example policies users can use to base their policy on. == Release Notes == -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

devel-announce April 2022