F35 Change: GHC 8.10 and Stackage lts-18 (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/GHC_8.10_%26_Stackage_18 == Summary == The GHC Haskell compiler will be updated from major version 8.8 to 8.10, and Haskell packages will be updated from Stackage LTS 16 to LTS 18 versions. == Owner == * Name: [[User:Petersen| Jens Petersen]] (Haskell SIG) * Email: == Detailed Description == For Fedora 35, the GHC Haskell compiler will be updated from version 8.8.4 to the latest stable 8.10.5 release (rebasing from the ghc:8.10 module stream). 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 16 to latest LTS 18 release. Haskell packages not in Stackage will be updated to the latest appropriate version in the upstream [https://hackage.haskell.org Hackage] package repository. On the s390x architecture, ghc-8.10 now supports the llvm backend, which should improve s390x performance significantly. == Benefit to Fedora == Fedora users will benefit from access to the latest stable Haskell compiler release, package tools, and current stable Haskell packages from Stackage LTS. GHC 8.10 features performance improvements, new language extension features, and bugfixes (see the release notes linked in the Documentation section for more details). == Scope == * Proposal owners: ** rebase ghc to 8.10.5 ** update ghc-rpm-macros to the final version for F35 [done] ** refresh packagings with the latest cabal-rpm release ** update packages to latest [https://www.stackage.org/lts-18.1 Stackage LTS 18.1] versions using cabal-rpm ** build all the packages in a Koji sidetag repo in dependency order ** When finished push all builds through Bodhi to Rawhide before the mass rebuild * Release engineering: N/A * Policies and guidelines: N/A (not needed for this Change) * Trademark approval: N/A (not needed for this Change) == Upgrade/compatibility impact == Any dropped packages will have obsoletes added. Otherwise there should not be any direct upgrade impact. Users' Haskell projects will get rebuilt with ghc-8.10 when they next build them and might need small tweaks. == How To Test == * install ghc and cabal-install * install pandoc, ShellCheck, git-annex * install ghc-*-devel or ghc-*-prof or ghc-*-doc * cabal-rpm builddep ; cabal install * test upgrades of F34 Haskell packages to F35 == 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 be updated from 3.0 to 3.2 and `stack` from 2.3 to 2.7. == Dependencies == (not provided) == Contingency Plan == * Contingency mechanism: (What to do? Who will do it?) ** Change owner will drop the new builds and revert back to the versions in F34. * Contingency deadline: Beta Freeze == Documentation == https://downloads.haskell.org/~ghc/8.10.5/docs/html/users_guide/8.10.1-notes.html -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
F35 Change: tzdata-minimal (Self-Contained Change proposal)
https://fedoraproject.org/wiki/Changes/tzdata-minimal == Summary == Split the tzdata package into two parts - tzdata and tzdata-minimal. tzdata will require tzdata-minimal. tzdata-minimal provides the minimal files needed to support UTC on containers. == Owner == * Name: Patsy Griffin (Franklin) * Email: pa...@redhat.com == Detailed Description == This is the first step towards providing support for a minimal, UTC only, version of tzdata for containers. The tzdata-minimal package will be a stand-alone, UTC only, subset of tzdata. The tzdata package will require tzdata-minimal. With this framework in place, other packages can develop code to detect a minimal tzdata installation. These packages will also need to provide appropriate messages when users request timezone information not available when only tzdata-minimal is installed. == Feedback == We have had requests for this functionality in order to support minimal container installations. Currently some container kickstart installations already ad hoc remove most of the timezone information provided by tzdata, leaving only UTC support available. This change provides a formal method of providing this support. Both the glibc and python teams are aware of this proposed change. This change does not currently require changes in their code. The goal is for those packages that currently require tzdata as part of their build or install, move towards recommending tzdata instead. == Benefit to Fedora == This change will reduce the size of base container installations. == Scope == * Proposal owners: Implement the proposal. * Other developers: Developers need to ensure that their packages continue to build and install with the new split tzdata/tzdata-minimal package changes. * Release engineering: No coordination required with Release Engineering. * Policies and guidelines: The policies and guidelines do not need to be updated. * Trademark approval: N/A (not needed for this Change) * Alignment with Objectives: N/A == Upgrade/compatibility impact == The only visible change will be a new package tzdata-minimal required by tzdata. == How To Test == Run a dnf upgrade of tzdata and observe that tzdata-minimal is now also installed as a dependency. == User Experience == Users will see that new updates to tzdata include a new package dependency on tzdata-minimal. == Dependencies == This change does not require or depend on changes to other packages. However, we hope that dependent packages will work towards recommending tzdata for builds and installs rather than requiring it. == Contingency Plan == * Contingency mechanism: If we are unable to complete this feature by the final development freeze, we will revert to the shipped configuration. * Contingency deadline: 100% Code complete deadline * Blocks release? No == Documentation == No documentation changes are needed at this time. == Release Notes == The tzdata package is now divided into a UTC only package, tzdata-minimal, and tzdata. -- Ben Cotton He / Him / His Fedora Program Manager Red Hat TZ=America/Indiana/Indianapolis ___ devel-announce mailing list -- devel-announce@lists.fedoraproject.org To unsubscribe send an email to devel-announce-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Re: F35 Change: Disable SHA1 In OpenDNSSec (Self-Contained Change proposal)
Hi Paul, all, On Tue, Jun 29, 2021 at 1:40 AM Paul Wouters wrote: > > On Mon, 28 Jun 2021, Ben Cotton wrote: > > > https://fedoraproject.org/wiki/Change/DisableSHA1InOpenDNSSec > > > == Detailed Description == > > > > OpenDNSSec changed the default behavior to not include SHA1 DS by > > default, and added the -sha1 knob as an immediately-deprecated > > compatibility knob in version 2.1.0 (2017-2): "OPENDNSSEC-552: By > > default ‘ods-enforcer key export –ds’ included the SHA1 version of the > > DS. SHA1 use is discouraged in favour of SHA256. To get the SHA1 DS > > use the –sha1 flag. This flag is immediately deprecated and will be > > removed from future versions of OpenDNSSEC." (see ChangeLog: > > https://www.opendnssec.org/archive/releases/ ). > > > > The proposal is to disable the -sha1 knob in Fedora. I will also open > > an issue upstream to remove all the sha1-related code. > > This change makes me a bit nervous, and I'm the author of RFC 8624 that > recommennds not using SHA-1 for DS/CDS records anymore. > > https://datatracker.ietf.org/doc/html/rfc8624#section-3.3 > > > Supporting statement > > [https://www.icann.org/en/blogs/details/its-time-to-move-away-from-using-sha-1-in-the-dns-24-1-2020-en > > [from ICANN] (2020-1-24): "Now is the time for administrators of zones > > at all levels of the DNS to stop using SHA-1 and change to algorithms > > using stronger hashes." > > While this is true, the order of where things need to change are: > > 1 Discourage, but not block, the use of SHA-1. Eg remove it from the default > set. > 2 Ensure the migration of SHA-1 based records to SHA-256 is taking place > 3 remove support for SHA-1 > > This plan assumes we are in phase3. I would say we are in phase2. > > Remember, any domain that depends on SHA-1 is going to be more secure > than being marked as insecure because SHA-1 is rejected. This is somewhat > different from like SHA-1 support for authentication where the rejection > of a weaker algorithm forces the use of a stronger algorithm. > > The DNSSEC fallback when an algorithm is not supported is to go insecure, > not insist on a more secure SHA-2 that is not there. With DNSSEC, > there is not client-server exchange like with TLS or IPsec. There is > a producer on one end, and a consumer on the other end. The two do not > negotiate crypto parameters. > > > == Benefit to Fedora == > > * This change makes sure OpenDNSSec in Fedora follows ICANN's > > guidelines and does not propose SHA1 DS. This is is needed given the > > [https://sha-mbles.github.io/ latest attacks against SHA-1]. More > > in-depth articles are available > > [https://www.dns.cam.ac.uk/news/2020-01-09-sha-mbles.html there] and > > [https://mailarchive.ietf.org/arch/msg/dnsop/hA4Ur9qxRJIUo13Pjpmrm_va7cs/ > > I know that a few people believe that shambles can in theory be abused > with DNSSEC, but a lot of people also believe the constrains of DNS > RRsets make this impossible. But even _if_ it is possible, it would > only affect multiple domains that share the same private key that made > the SHA-1 signature. And then we are talking about RRSIG records and > not, as in this proposal, the DS/CDS RDATA content. > > > Patch the enforcer so that bsha1 is not honored anymore: > > I don't think fedora should move faster than upstream opendnssec. I > believe the people at the IETF and the software developers of the DNS > software are more aware of where we are in the migration path than > individual Fedora developers. Thanks a lot for your input. I am withdrawing the change proposal now as it makes no sense indeed to have Fedora move faster than upstream on this. Regards, François > > == Upgrade/compatibility impact == > > Zones with SHA-1 signatures can be migrated to SHA-256 by re-signing the > > zone. > > The RRSIG signature is not related to the DS signature. Zone resigning > is something completely different from the DS/CDS records. Those records > are signed by the parent zone, and use whatever algorithm the parent > zone uses, which the child zone cannot dictate. > > > This change might break (very old) clients that only recognize SHA-1 > > but these should already be broken (on the Internet at least) because > > the root zone is signed with SHA-256 only. > > The root zone has no DS record, so this statement does not make sense. > The RRSIG signature algorithm is unrelated to the DS/CDS record RRdata > that contains a hash of the child's public key, where the hash is created > with SHA-1 or SHA-2. > > > == User Experience == > > > > OpenDNSSec in Fedora can currently be used to sign zones with SHA1. > > With this change, this will no longer be possible. The migration from > > SHA1 is underway anyway. > > So there are two things that really need to be clarified for this > proposal. Is it talking about DS/CDS signature algorithm as per IANA > registry http://www.iana.org/assignments/ds-rr-types, or are we talking > about DNSKEY signature algorithm, that is responsble for signing all
