Advice needed: Pantheon desktop broken on Fedora 37 (yes, worse than usual)
by Fabio Valentini
Hello all,
I'm not quite sure how to approach this problem, but as it stands, the
packages for the Pantheon DE and associated "elementary" applications
will probably be mostly broken when Fedora 37 will be released.
Every major GNOME update comes with problems for Pantheon (especially
due to mutter API changes), but this time is *much* worse due to the
additional libsoup 2 -> 3 transition.
Upstream development of the Pantheon / elementary projects is now
focused on finally getting elementary OS 7 out the door (which was
already supposed to have happened, it will be based on ubuntu 22.04
LTS, after all). Support for things that are in the far-off future
(like libsoup3, webkit2gtk-4.1, etc.) are low priority for them,
especially given their diminished manpower.
(The list of currently broken or "in danger of being broken on Fedora
38+" applications and components is included below, including links to
upstream tickets.)
I am already at my limit with the time that I can invest into Fedora,
and GObject C is the bane of my existence - so I can't really help
with these porting efforts, and upstream development is (rightfully
so) focused on their own, more important problems right now.
I doubt that these problems will be fixed in time for the release of
Fedora 37. And because many of these problems result in outdated,
crashing, failing-to-install or failing-to-build packages, I don't
think this is a good outcome at all, least for my users. Rather than
leave the DE available, but in an utterly broken and useless state,
I'd rather remove it from Fedora 37 altogether.
This set of packages also has at least some sentimental value to me,
because they were my first contributions to Fedora - first in COPR,
then getting them through package review (my first review request was
for the granite GTK widget library for elementary applications, which
was reviewed by rathann and ngompa).
The Pantheon components and elementary apps are also probably the
packages with the biggest number of actual users (the combination of
"Pantheon on Fedora" is quite popular for something that's not
available as an official Spin), maybe except for Syncthing, among all
the packages that I maintain.
So, I don't see any "good" way to handle this right now. If somebody
can give me any advice for what to do in this situation, I would be
grateful (even if the advice is: "yes, retire the packages, rather
than leave them broken, they can be added back once they have been
fixed").
Thanks,
Fabio
------------------------------------------------------------------------
Some critical Pantheon DE components that are currently broken:
- gala (window manager): https://github.com/elementary/gala/issues/1447
broken due to mutter API changes between 43.alpha and 43.beta
fails to build + fails to install on Fedora 37+
- elementary-greeter (LightDM greeter):
https://github.com/elementary/greeter/issues/617
broken due to mutter API changes
fails to build + fails to install on Fedora 37+
- wingpanel (top panel, application launcher, indicators, etc.):
https://github.com/elementary/wingpanel/issues/462
broken due to broken gala, and also because of mutter API changes
fails to build + fails to install on Fedora 37+
Creating a compat package for older versions of mutter has previously
worked to work around the worst problems, but it comes with its own
can of worms (i.e. you need to backport upstream patches for
compatibility with the latest gnome-settings-daemon version, etc.),
and this is not something that I can commit to doing again.
Additionally, some applications are broken:
- elementary-calendar: https://github.com/elementary/calendar/issues/756
broken because it directly links libsoup2, but also
evolution-data-server, which has transitioned to libsoup3, and
geocode-glib-1.0, which is the libsoup-2 version
fails to build / install on Fedora 37+
- elementary-mail: https://github.com/elementary/mail/issues/793
broken because it uses webkit2gtk-4.0, but also evolution-data-server,
which has moved to libsoup3
fails to build / install on Fedora 37+
- elementary-tasks: https://github.com/elementary/tasks/issues/340
broken because it uses libsoup2, but also evolution-data-server, and
geocode-glib-1.0, which is the libsoup-2 versionfails to build /
install on Fedora 37+
fails to build / install on Fedora 37+
Other applications aren't broken *yet*, but they will need to be
ported to new library versions at some point (for Fedora 38, or Fedora
39 at the latest, according to current plans for the removal of
libsoup2):
- elementary-photos: https://github.com/elementary/photos/issues/718
needs to be ported to webkit2gtk-4.1 / rest-1 / libsoup-3
- elementary-capnet-assist:
https://github.com/elementary/capnet-assist/issues/84 and 85
needs to be ported to webkit2gtk-4.1 and gcr-4.0
- switchboard-plug-onlineaccounts:
https://github.com/elementary/switchboard-plug-onlineaccounts/issues/243
needs to be ported evolution-data-server 3.45+ / libsoup-3
1 year, 7 months
F38 Proposal: SPDX License Phase 1 (Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/SPDX_Licenses_Phase_1
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 ==
Transition from Fedora's short name of licenses to standardized
[https://spdx.org/licenses/ SPDX license]
[https://spdx.dev/specifications/ formula].
== Owner ==
* Name: [[User:msuchy| Miroslav Suchý]]
* Name: [[User:jlovejoy| Jilayne Lovejoy]]
* Name: [[User:ngompa| Neal Gompa]]
* Name: [[User:dcantrell| David Cantrell]]
* Name: [[User:rfontanaref| Richard Fontana]]
* Name: [[User:mattdm| Matthew Miller]]
<!-- Include you email address that you can be reached should people
want to contact you about helping with your change, status is
requested, or technical issues need to be resolved. If the change
proposal is owned by a SIG, please also add a primary contact person.
-->
* Email: msuchy(a)redhat.com, dcantrell(a)redhat.com, jlovejoy(a)redhat.com,
ngompa13(a)gmail.com, rfontana(a)redhat.com
== Detailed Description ==
In the past, Fedora decided to use short names for licenses. Although
we documented the short names very well. The identifiers were never
standard. In the meantime, SPDX identifiers become standard, and
[https://wiki.spdx.org/view/Business_Team/Adoption other SW vendors
start using it].
In this phase, we want to provide documentation and tooling to allow
maintainers to begin using SPDX license ids instead of the old Fedora
short names. This move is opt-in. There will be
[[Changes/SPDX_Licenses_Phase_2|Phase 2]], where we identify the
remaining packages and help them to migrate to the SPDX formula.
== Feedback ==
Ancient [https://lists.fedoraproject.org/archives/list/legal@lists.fedoraproject.o...
feedback from SPDX organization].
Summary from [https://lists.fedoraproject.org/archives/search?q=spdx&page=1&mlist=legal...
fedora-legal mailing list]: we want this to happen, but this is big
scope and likely will happen over more than one release.
Summary from packaging-committee:
* [https://pagure.io/packaging-committee/pull-request/971#]: older PR
to change packaging guidelines
* [https://pagure.io/packaging-committee/pull-request/1142]: present
PR that needs more updating
Summary from devel-list: TBD
== Benefit to Fedora ==
The use of a standardized identifier for license will align Fedora
with other distributions. And allows efficient and reliable
identification of licenses.
== Scope ==
* Proposal owners (things sorted by done/todo and by priorities):
** Miroslav Suchý: license-fedora2spdx - done
** Jilayne Lovejoy: map rest of Fedora licenses to SPDX ids - done
** David Cantrell: create machine-readable format and new repo - done
** David Cantrell: merge mapping of Fedora licenses to SPDX ids to new
data format/repo - done
** Richard Fontana & Jilayne Lovejoy: review update all licensing info
and legal pages in wiki - in process
** Jilayne Lovejoy & Richard Fontana: create and populate new Docs
pages for legal and licensing info - in process
** Miroslav Suchy - create
[https://gitlab.com/fedora/legal/fedora-license-data
fedora-license-data package] (with data from rpminspect-data-fedora) -
TODO
** David Cantrell: separate licenses from rpminspect-data-fedora
[https://bugzilla.redhat.com/show_bug.cgi?id=2077914 BZ 2077914] -
TODO
** Miroslav Suchý: allow `license-validate` to use spdx - TODO
** David Cantrell: generate from license data to new Docs page similar
to [https://fedoraproject.org/wiki/Licensing:Main#Software_License_List
Licensing:Main]
** SOMEBODY: create a webhook that updates Docs page after the merge
to fedora-license-data - TODO
** Jilayne Lovejoy: prepare PR for updates to packaging guidelines -
in the process [https://pagure.io/packaging-committee/pull-request/1142]
** SOMEBODY: help maintainers who want to change license string to
SPDX identifiers proactively.
* Out of Scope: In this phase, we do not target to move **all**
packages to SPDX identifiers. That will be done in
[[Changes/SPDX_Licenses_Phase_2|Phase 2]]. In
[[Changes/SPDX_Licenses_Phase_2|Phase 2]] we will identify the
remaining packages and open BZ or PR.
* Other developers:
Early adopters can migrate their License tag to the SPDX identifiers.
Proposal owners will gather feedback and will work on potential
problems.
We want to have all bits ready so that maintainers can start changing
the spec files just after Fedora 37 branching (summer 2022).
* Release engineering:
* Policies and guidelines: Licensing page, packaging guidelines has to
be altered.
* Trademark approval: N/A (not needed for this Change)
* Alignment with Objectives:
== Upgrade/compatibility impact ==
License strings are not used anything in run time. This change will
not affect the upgrade or runtime of Fedora.
During the transition period, developer tools like rpminspect,
licensecheck, etc. may produce false negatives. And we have to define
a date where we flip these tools from old Fedora's short names to the
SPDX formula.
== How To Test ==
Users should not need any testing. These steps are for package maintainers:
* Fetch your license string from `License` tag in SPEC file.
* Test that your current Fedora's short name is correct. E.g.
$ license-validate -v 'MIT or GPLv1'
Approved license
* Convert license string to SPDX formula:
$ license-fedora2spdx 'MIT or GPLv1'
Warning: more options how to interpret MIT. Possible options:
['Adobe-Glyph', 'MIT-CMU', 'MIT-CMU', 'HPND', 'HPND', 'no-spdx-yet
(MIT license (also X11))', 'SGI-B-2.0', 'SGI-B-2.0', 'SMLNJ',
'MIT-enna', 'MIT-feh', 'mpich2']
mpich2 or GPL-1.0-only
In this example, the short name `GPLv1` can be converted straight to
`GPL-1.0-only`. But short name `MIT` stands for several licenses with
different [https://spdx.org/licenses/ SPDX identifiers]. You have to
examine what license is package actually using. `license-fedora2spdx`
will try to convert the formula and use one of the options but without
any heuristics. You need to manually review the license.
You can check if SPDX formula is correct using:
$ license-validate -v --file FIXME "MIT-CMU or GPL-1.0-only"
== User Experience ==
Users should be able to use standard software tools that audit
licenses. E.g. for Software Bills of Materials.
== Dependencies ==
No other dependencies.
== Contingency Plan ==
* Contingency mechanism: In this first phase, if something goes wrong,
we can 'git revert' each change in dist-git. It is expected that in
the first phase, there will be only a few packages altered. It may be
a few hundred, but it is still doable to revert.
* Contingency deadline: Beta freeze. But it is expected that not all
packages will be converted by that time and the change will continue
in the next release.
* Blocks release? No. This change has no impact on runtime of any package.
== 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 year, 8 months
glibc 2.36 and DT_HASH (preserving it for F37+)
by Neal Gompa
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!
1 year, 8 months
tinyxml2 soname bump
by Rich Mattes
Hi,
I'm planning on upgrading tinyxml2 to version 9 in rawhide in the coming
week, which will include a soname bump. Affected packages are:
Macaulay2-0:1.19.1-2.fc37.src
bullet-0:3.08-3.fc36.src
cppcheck-0:2.7.4-1.fc37.src
dvblinkremote-0:0.2.0-0.25.beta.fc36.src
gazebo-0:10.1.0-27.fc36.src
linbox-0:1.6.3-11.fc36.src
vdr-epg2vdr-0:1.2.7-1.fc37.src
vdr-osd2web-0:0.2.54-12.fc37.src
I'll take care of the rebuilds in a side tag.
Rich
1 year, 8 months
F37 proposal: Public release of the Anaconda Web UI preview image
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Anaconda_Web_UI_preview_image
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 ==
The work on Web UI for the Anaconda installer has advanced enough so
that it is possible to create and publish self contained preview
images.
== Owner ==
* Name: [[User:m4rtink| Martin Kolman]]
* Email: mkolman(a)redhat.com
== Detailed Description ==
Even though still very simple the new Anaconda Web UI is now far
enough to support a simple installation workflow from a self-contained
image while demonstrating all the main aspects of the new UI, such as:
* flexible Wizard layout
* responsive PatternFly components
* new style built-in help
* local and remote access to the Web UI
For this we will create a self-contained boot.iso style image with a
built-in tar-payload (so that the image can work even without network
access) based on the latest Anaconda upstream code.
We aim to have the image available for download just after the F37
release (so that the tar-payload can contain final F37 release
content) and then updated automatically in regular intervals.
That way the rather active Web UI development of the Web UI will be
reflected in the up-to-date installation image, as well as any
feedback and community PRs.
== Benefit to Fedora ==
The Anaconda Web UI will provide modern responsive user interface
based on a well known
and widely used toolkit (PatternFly) and backed by proven Cockpit tooling.
The screen layout is based on latest UX design guidelines as well as
usability testing of the new interface and extensive mockup work.
There are improvements in developer experience as well due to the more
modern & more mainstream UI technology chosen and powerful Cockpit
test tooling (rich unit-test as well as pixel-test framework). The
stateless property of the Web UI allows almost live-coding style of UI
development. This should make it easier to work on the Anaconda Web UI
for not only the Anaconda team, addon developer but also for any
interested contributors.
Remote Web UI access should also provide a much better experience than
the slow and inefficient VNC based remote GUI installation support
Anaconda has today. Due to no need for local rendering remotely driven
GUI installations on a constrained hardware with minimal installation
images should become possible.
== Scope ==
* Proposal owners:
The Anaconda team will setup and maintain an automated Web UI preview
image creation pipeline, with the image being available via a web
server on the Fedora infrastructure.
It will be a '''preview image only''', not an official Fedora
deliverable and it will not influence Fedora release criteria in any
way.
* Other developers:
Other developers and Fedora users are welcome to try the image once it
is released and to provide feedback.
* 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 ==
(not supplied)
== How To Test ==
Download the Anaconda Web UI preview image and boot it on VM or
hardware that contains no important data.
Install using the Web UI locally, alternatively try using the Web UI remotely.
The installed OS should be functional but its testing or any issues
with it are currently out of scope for the Anaconda Web UI preview
image.
To provide feedback use one of the Anaconda team communication channels:
* IRC: [https://web.libera.chat/#anaconda #anaconda] on libera.chat
* mailing list: anaconda-devel(a)lists.fedoraproject.org -
https://lists.fedoraproject.org/archives/list/anaconda-devel@lists.fedora...
* Github Discussion: https://github.com/rhinstaller/anaconda/discussions
== User Experience ==
Should be improved compared to the current GTK interface.
== Dependencies ==
(not supplied)
== Contingency Plan ==
* Contingency mechanism: If we hit some blocking technical issues, the
image will be published later.
* 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)
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
1 year, 8 months
F38 proposal: Strong crypto settings: phase 3, forewarning 2/2
(System-Wide Change proposal)
by Ben Cotton
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.o...
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
1 year, 8 months
Minizip renaming Fedora Change
by Lukas Javorsky
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>
1 year, 8 months
nspawn for rawhide?
by Kevin Fenzi
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
1 year, 8 months
