devel August 2022

devel@lists.fedoraproject.org

196 participants
254 discussions

F38 proposal: Strong crypto settings: phase 3, forewarning 2/2 (System-Wide Change proposal)
by Ben Cotton 17 Sep '22

17 Sep '22

https://fedoraproject.org/wiki/Changes/StrongCryptoSettings3Forewarning2 == Summary == Cryptographic policies will be tightened in Fedora ''38''-39, SHA-1 signatures will no longer be trusted by default. Fedora ''38'' will do a "jump scare", introducing the change but then reverting it in time for Beta. Test your setup with TEST-FEDORA39 today and file bugs in advance 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]]. 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 (no 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 (no 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 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. So, 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 [https://datatracker.ietf.org/doc/rfc8996 deprecated], 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 TEST-FEDORA39 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 F37 timeframe to cut down on F38 FTBFS. * Policies and guidelines: update needed 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 == See "User experience". Upgrade-time issues aren't specifically anticipated; if any were to arise, testing should find them in ''Fedora 38''-times, to be fixed by Fedora 39 release at the latest. Administrators willing to sacrifice security can apply LEGACY or FEDORA38 policies. == How To Test == === Testing actively === On a ''Fedora 38 rawhide'' system, install crypto-policies-scripts package and switch to a more restrictive policy with `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 TEST-FEDORA39:SHA1`, 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. Especially brave souls can dare to try `update-crypto-policies --set FUTURE` instead, though this policy is more aggressive than the upcoming defaults. === Testing passively === On a ''Fedora 38 released'' system, 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 36-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 == A small coordinated change with openssl is required. In Fedora 38, openssl should start distrusting SHA-1 signatures when used with no configuration file. This does not affect the majority of scenarios, only applications that do not follow system-wide cryptographic policies. All reverse dependencies of core cryptographic libraries are affected, especially openssl ones relying on SHA-1 signatures. == Contingency Plan == * Contingency mechanism: not needed for F38, change will be reverted before Beta anyway * Contingency deadline: not needed for F38, change will be reverted before Beta anyway * Blocks release? No == Documentation == Workaround API should be added to [[SHA1SignaturesGuidance | SHA1SignaturesGuidance]]. Packaging guidelines should be modified accordingly. == Release Notes == To be done, similarly to https://pagure.io/fedora-docs/release-notes/issue/829 -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

11 25

Inactive packagers to be removed after the F37 release
by Ben Cotton 16 Sep '22

16 Sep '22

Hello everyone! I just completed the first run of FESCo's newly approved Inactive Packager Policy[1]. Packagers that have been identified as inactive have a ticket in the find-inactive-packagers repo[2]. One week after the F37 final release, packagers who remain inactive will be removed from the packager group. (Note that pagure.io is one of the systems checked for activity, so commenting on your ticket that you're still around will prevent you from showing up in the second round.) Since this is the first time we've done something like this, it could be a little rough. I appreciate your patience and understanding. If you have suggestions for improvement, look for the open feature issues[3] and file an issue in the find-inactive-packagers repo[4] if it's not there already. For the curious, here are the stats from today's run: 2550 users checked 913 of those had no activity on src.fedoraproject.org or pagure.io 835 of those had no activity in Bodhi 812 of those had no activity on the mailing lists 606 of those (~24% of packagers) had no activity in Bugzilla. The script took a little under three hours to run. [1] https://docs.fedoraproject.org/en-US/fesco/Policy_for_inactive_packagers/ [2] https://pagure.io/find-inactive-packagers/issues?tags=inactive_packager&sta… [3] https://pagure.io/find-inactive-packagers/issues?tags=feature [4] https://pagure.io/find-inactive-packagers/new_issue -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis _______________________________________________ devel-announce mailing list -- devel-announce(a)lists.fedoraproject.org To unsubscribe send an email to devel-announce-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedorapr… Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

37 128

Minizip renaming Fedora Change
by Lukas Javorsky 16 Sep '22

16 Sep '22

Hi fellow contributors, Upstream has reported a request for minizip naming change from "minizip" to "minizip-ng" (minizip-ng is the official name of the upstream package right now). As Fedora should match the upstream naming, I believe this change is necessary. Another naming change is required for the "minizip-compat" package which is the subpackage of the "zlib" package. Upstream requests that we should rename "minizip-compat" to "minizip". I agree with renaming this package as well, however, this could lead to multiple confusions maybe even conflicts for the users. The problem with renaming this package right after renaming the "minizip-ng" could be that the users may be confused about which package is the right "minizip" for them. I believe we could rename the "minizip-compat" to the "minizip" after some larger time period so every package that requires "minizip" changes the requirements to "minizip-ng" and there is no confusion anymore. The first step I want to do is to create a Fedora Change, which contains this whole process and is well communicated within the community. This email serves as a heads-up and also opens a possibility for any tips that you can give me with this change. This is my first time doing a change like this so it may have some bumps along the way, but I'm willing to learn and improve, so feel free to give me any advice you think could benefit me with this process. Thank you for understanding and sorry for quite a long email. Lukas -- S pozdravom/ Best regards Lukáš Javorský Software Engineer, Core service - Databases Red Hat <https://www.redhat.com> Purkyňova 115 (TPB-C) 612 00 Brno - Královo Pole ljavorsk(a)redhat.com <https://www.redhat.com>

7 13

nodejs-electron
by Andreas Schneider 15 Sep '22

15 Sep '22

Hello! Over the past 8 month, I've been working on getting Electron [1] built on Fedora. Yesterday I was finally able to do the first working build for Fedora Rawhide [2]. This was possible because we finally have ffmpeg [3] in Fedora. My use for Electron is that I want to run signal-desktop [4] on Fedora. You can get electron and signal-packages packages for it at [5]. Is there interest to bring nodejs-electron into Fedora and if yes, would someone be interested to maintain it? I don't have the time to maintain it but I'm happy to help as a co-maintainer. Best regards Andreas [1] https://www.electronjs.org/ [2] https://build.opensuse.org/package/show/network:im:signal/nodejs-electron [3] https://src.fedoraproject.org/rpms/ffmpeg/ [4] https://build.opensuse.org/package/show/network:im:signal/signal-desktop [5] https://download.opensuse.org/repositories/network:/im:/signal/ Fedora_Rawhide/x86_64/

8 25

hardened memory allocate port to linux-fedora system for secutiry
by martin luther 15 Sep '22

15 Sep '22

should we implement https://github.com/GrapheneOS/hardened_malloc/ it is hardened memory allocate it will increase the security of fedora according to the graphene os team it can be ported to linux as well need to look at it

10 17

glibc 2.36 and DT_HASH (preserving it for F37+)
by Neal Gompa 14 Sep '22

14 Sep '22

Hey all, It seems that upstream glibc disabled support for generating DT_HASH tables for its libraries and binaries, which breaks Linux games that use Epic Games' Easy Anti-Cheat (EAC). There's a pretty decent write-up about this on LWN: https://lwn.net/Articles/904892/ Can we turn this back on for Fedora glibc until we can get Epic to make fixes for this and roll them out? I'd really like my Linux games to not break on upgrading to Fedora 37... -- 真実はいつも一つ！/ Always, there's only one truth!

14 21

Thoughts welcome: interface between automated test gating and the "critical path"
by Adam Williamson 13 Sep '22

13 Sep '22

Hi folks! I have one of those definitional quandaries and I figured I'd throw it at the lists for some input. Right now, we kind of take advantage of the "critical path" concept for automated update testing and gating via openQA. openQA does not test all updates, only critical path updates plus updates containing any package on a short allowlist. Bodhi and Greenwave do not gate all updates on the openQA tests since not all updates are tested; again we use the critpath definition. If an update is critical path, it gets gated on the openQA tests. If it isn't, it doesn't. If you've been paying attention, that means there's a bit of a hole: the packages on the 'allowlist'. These are tested, but not gated. What's on the allowlist? Basically, FreeIPA-related packages. We have a good set of FreeIPA tests in openQA, and both I and the FreeIPA team wanted relevant updates to be tested with them. But those packages are not on the critical path. So I set up this 'allowlist' mechanism. However, the lack of gating kinda sucks. I would much prefer if we could gate these updates as well as just testing them. The obvious thing to do is add the FreeIPA-related packages to the critical path, but that really is not supported by the critical path definition: https://fedoraproject.org/wiki/Critical_path_package which defines it as packages required to "perform the most fundamental actions on a system", with a list of specific areas, none of which is "run a domain server". So...what to do? I can think of I guess four options: 1. Broaden the definition of the "critical path" somehow. We could just write in that it includes FreeIPA functionality, I guess, though that seems special purpose. We could broaden it to include any functionality covered by the release criteria, which would be quite a big increase but seems like a reasonable and concise definition. Or we could write in that it includes any functionality that is exercised by the gating openQA tests, though that seems a bit arbitrary - there's no particularly great organizing principle to the openQA tests we choose to run on updates, if I'm honest, it's a sort of grab bag I came up with. 2. Keep the current "critical path" concept but define a broader group of "gated packages" somewhere (could be comps or somewhere else). This would require engineering work - we'd have to touch probably the openQA scheduler, Bodhi, and greenwave configs. It's also another maintenance burden. 3. Add gating config to each allowlisted package repo's gating.yml one by one. I don't really like this option. It'd be a chunk of work to do initially, and multiples the maintenance required when the list of tests to gate on changes for some reason. 4. Do nothing, just keep only gating things that are "critical path" on the current definition. In a utopian future, we'd manage to deploy openQA in the cloud or get a giant pile of super fast servers so we could test and gate *every* update, and this wouldn't be an issue any more. What do folks think? Any preferences? Thanks! -- Adam Williamson Fedora QA IRC: adamw | Twitter: adamw_ha https://www.happyassassin.net

9 17

nspawn for rawhide?
by Kevin Fenzi 13 Sep '22

13 Sep '22

Greetings everyone. Many years ago mock introduced and then made default it's isolation to use systemd-nspawn instead of chroot. Shortly after the nspawn isolation was added, it was used in fedoraproject koji builds, but there were issues and since then the fedoraproject koji has defaulted to using chroot isolation. Releng has had a ticket open for a long time to switch ( https://pagure.io/releng/issue/6967 ) I think the two items listed there (kernel bind mounts and loop devices) have long since been fixed, so I would like to propose we switch rawhide to using nspawn and see if any other issues show up. If everyone is ok with it, I can enable it (just for rawhide) and we can look for issues with composes or any other items. At least then we would have a good list of things we would like to fix. If it turns out things just work ok we can leave it enabled. I think moving to this will: * More closely match developers local test mock builds. * Provide better isolation for builds * Help with resources as systemd-nspawn is a lot more cgroup aware than chroot * Allow us to close a 5 year old ticket. ;) Thoughts? kevin

10 15

F38 proposal: Minizip renaming (Self-Contained Change proposal)
by Ben Cotton 13 Sep '22

13 Sep '22

https://fedoraproject.org/wiki/Changes/MinizipRenaming This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee. == Summary == Renaming the "minizip" package to "minizip-ng" and renaming the "minizip-compat" zlib subpackage to "minizip" to align with the upstream naming. == Owner == * Name: [[User:ljavorsk| Lukas Javorsky]] * Email: ljavorsk(a)redhat.com == Detailed Description == Upstream has changed the naming of the "minizip" package to "minizip-ng" and we should follow their naming so there is no confusion about which package is the right one. Upstream has also requested to rename the "minizip-compat" zlib subpackage to "minizip" which is the right naming for the package. The "minizip" and "minizip-compat" provides different shared libraries which prevent us from conflicting sonames. The plan behind this change can be put into x steps which will be completed separately and in the given order: ''NOTE: All of the Provides and Obsoletes will be added to the *-devel subpackages as well.'' 1) Create a new package "minizip-ng" which will `Provides: minizip = %{sameevr}` and `Obsoletes: (minizip < 3.0.2-7 and minizip > 3.0.0-1)` ''NOTE: The versions I choose here are the safe versions that create a space for possible "minizip-compat" rebases'' 2) Rebuild all of the packages that BuildRequire/Require "minizip" package to BuildRequire/Require new "minizip-ng" package 3) Retire the "minizip" package following the [https://docs.fedoraproject.org/en-US/package-maintainers/Package_Retirement… Package Retirement Process] 4) Wait for the Fedora 40 when it's ensured that every user has updated at least to the Fedora 38. Remove the `Provides` and `Obsoletes` from the "minizip-ng" package 5) Rename the "minizip-compat" to the "minizip" package and add `Provides: minizip-compat = %{sameevr}` and `Obsoletes: minizip-compat < 1.2.12` == Feedback == Early feedback from the community is possite, the feedback is located in this [https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org… Email thread] == Benefit to Fedora == Fedora should always respect upstream package naming, so the users are not confused about which package are they installing. This naming change will align the naming with the upstream. == Scope == * Proposal owners: New package "minizip-ng" will be created, and several changes in "minizip-compat" package which are described in the Detailed Description. * Other developers: Change the names of their BuildRequires/Requires accordingly. * Release engineering: No action required * 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 == When following the plan in Detailed Description there will be no need for manual action. Everything will be handled by the automated dnf upgrade. == How To Test == == User Experience == == Dependencies == List of the packages from Fedora 37 === minizip === repoquery --whatrequires "*libminizip.so.3*" | pkgname | uniq R-libSBML collada-dom dolphin-emu dolphin-emu-tool java-libsbml keepassxc libnuml librasterlite2 libsbml libspatialite libxlsxwriter minizip-devel perl-LibSBML python3-libsbml ruby-SBML sigil vxl xiphos zfstream === minizip-compat === repoquery --whatrequires "*libminizip.so.1*" | pkgname | uniq chromedriver chromium chromium-headless domoticz hashcat libdigidocpp minizip-compat-devel springlobby == Contingency Plan == * Contingency mechanism: Remove the builds created and revert shipped changes. Done by any Fedora packager (preferred by the one who knows about this change) * Contingency deadline: Beta freeze * Blocks release? No ''NOTE: If we don't finish this change to the deadline, it is possible to just complete this change with the next release.'' == Documentation == [https://github.com/zlib-ng/minizip-ng/issues/358 Upstream issue] [https://bugzilla.redhat.com/show_bug.cgi?id=2037245 Bugzilla tracker] -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis

4 4

Bump f38 .so for libid3tag
by Leigh Scott 11 Sep '22

11 Sep '22

Switching upstream has increased the .so version from libid3tag.so.0 to libid3tag.so.0.16.2 I plan to do the rebuilds myself after checking everything builds ok in copr. Affected packages Fedora: audacity-0:3.1.3-5.fc37.x86_64 easytag-0:2.4.3-16.fc37.x86_64 gtkpod-0:2.1.5-21.fc37.x86_64 imlib2-id3tag-loader-0:1.7.4-3.fc37.x86_64 mp3fs-0:1.1.1-4.fc37.x86_64 sonic-visualiser-0:4.5-2.fc37.x86_64 sox-0:14.4.2.0-33.fc37.x86_64 Rpmfusion: audacity-freeworld-0:3.1.3-4.fc37.x86_64 libmp3splt-0:0.9.2-13.fc37.x86_64 minidlna-0:1.3.0-8.fc37.x86_64 mixxx-0:2.3.3-2.fc37.x86_64 moc-0:2.6-0.46.svn3005.fc37.x86_64 mpd-1:0.23.9-1.fc37.x86_64 vdr-mp3-0:0.10.4-6.fc37.x86_64

4 4

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

devel August 2022