Wine MinGW system libraries
by Zebediah Figura
Hello all,
I'm a contributor to the Wine project. To summarize the following mail,
Wine needs special versions of some of its normal dependencies, such as
libfreetype and libgnutls, built using the MinGW cross-compiler, and I'm
sending out a mail to major distributions in order to get some feedback
from our packagers on how these should be built and packaged.
For a long time Wine has built all of its Win32 libraries (DLLs and
EXEs) as ELF binaries. For various reasons related to application
compatibility, we have started building our binaries as PE instead,
using the MinGW cross-compiler. It is our intent to expand this to some
of our dependencies as well. The list of dependencies that we intend to
build using MinGW is not quite fixed yet, but we expect it to include
and be mostly limited to the following:
* libvkd3d
* libFAudio
* libgnutls
* zlib (currently included via manual source import)
* libmpg123
* libgsm
* libpng
* libjpeg-turbo
* libtiff
* libfreetype
* liblcms2
* jxrlib
and dependencies of the above packages (not including CRT dependencies,
which Wine provides).
There is currently some internal discussion about how these dependencies
should be built and linked. There are essentially three questions I see
that need to be resolved, and while these resolutions have a significant
impact on the Wine building and development process, they also have an
impact on distributions, and accordingly I'd like to get input from our
packagers to ensure that their considerations are accurately taken into
account.
(1) Should we build via source import, or link statically, or dynamically?
Static linking and source imports are dispreferred by Fedora [1] [2], as
by many distributions, on the grounds that they cause duplication of
libraries on disk and in memory, and make it harder to update the
libraries in question (see also question 2). They also make building and
bisecting harder.
Note however that if they are linked dynamically, we need to make sure
that we load our packages instead of MinGW builds of open-source
libraries with applications ship with. Accordingly we need each library
to be renamed, and to link to renamed dependencies. For example, if
application X ships with its own copy of libfreetype-6.dll, we need to
make sure that our gdi32.dll links to libwinefreetype-6.dll instead, and
that libwinefreetype-6.dll links to libwineharfbuzz-0.dll and
winezlib.dll. I think, although I haven't completely verified yet, that
this can be done just with build scripts (i.e. no source patches), by
using e.g. --with-zlib=/path/to/winezlib.dll.
Accordingly, although static linking and source imports are generally
disprefered, it may quite likely be preferable in our case. We don't get
the benefits of on-disk deduplication, since Wine is essentially the
only piece of software which needs these libraries.
(2) If we use dynamic libraries, should dependencies be included in the
main wine package, or packaged separately?
This is mostly a question for packagers, although it also relates to (3).
I expect that Fedora (and most distributions) want to answer "packaged
separately" here, on the grounds that this lets them update (say) Wine's
libgnutls separately, and in sync with ELF libgnutls, if some security
fix is needed. There is a snag, though: we need libraries to be copied
into the prefix (there's some internal effort to allow using something
like symlinks instead, but this hard and not done yet). Normally we
perform this copy every time Wine is updated, but if Wine and its
dependencies aren't updated on the same schedule, we may end up loading
an old version of a dependency in the prefix, thus missing the point of
the update.
(3) If dependencies are packaged separately, should Wine build them as
part of its build tree (e.g. using submodules), or find and link
(statically or dynamically) to existing binaries?
Linking to existing binaries is generally preferable: it avoids
duplication on disk; it reduces compile times when compiling a single
package from source (especially the first time). However, we aren't
going to benefit from on-disk duplication. And, most importantly, unlike
with ELF dependencies, there is no standardized way to locate MinGW
libraries—especially if it comes to Wine-specific libraries. We would
need a way for Wine's configure script to find these packages—and
ideally find them automatically, or else fall back to a submodule-based
approach.
If we rely on distributions to provide our dependencies, the best idea I
have here would be something like a x86_64-w64-mingw32-pkg-config. And
if we use shared libraries rather than static, things get worse: we need
to know the exact path of each library and its dependencies so that we
can copy (or symlink) them into a user's WINEPREFIX.
For what it's worth, the current proposed solution (which has the
support of the Wine maintainer) involves source imports and submodules.
There's probably room for changing our approach even after things are
committed, but I'd still like to get early feedback from distributions,
and make sure that their interests are accurately represented, before we
commit. In short, it's not clear whether distributions want their
no-static-library policies to apply to us as well, or whether we're
enough of a special case and would be enough of a pain to package that
they'd rather we deal with the hard parts, and I don't want us to make
any assumptions.
ἔρρωσθε,
Zebediah
[1]
https://docs.fedoraproject.org/en-US/packaging-guidelines/#packaging-stat...
[2] https://fedoraproject.org/wiki/Bundled_Libraries
1 year, 11 months
OpenJDK and unremoved directories
by Vitaly Zaitsev
Hello.
I have a lot of unremoved directories and files in /usr/lib/jvm/:
$ ls -l /usr/lib/jvm/
total 140
drwxr-xr-x. 5 root root 4096 Sep 10 14:32
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
drwxr-xr-x. 3 root root 4096 Mar 14 2017
java-1.8.0-openjdk-1.8.0.121-10.b14.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Apr 21 2017
java-1.8.0-openjdk-1.8.0.131-1.b12.fc25.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc26.x86_64
drwxr-xr-x. 3 root root 4096 Oct 25 2017
java-1.8.0-openjdk-1.8.0.151-1.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Jan 24 2018
java-1.8.0-openjdk-1.8.0.161-0.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2018
java-1.8.0-openjdk-1.8.0.161-5.b14.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Mar 29 2018
java-1.8.0-openjdk-1.8.0.162-3.b12.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 18 2018
java-1.8.0-openjdk-1.8.0.171-1.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc27.x86_64
drwxr-xr-x. 3 root root 4096 Apr 25 2018
java-1.8.0-openjdk-1.8.0.171-4.b10.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 3 2018
java-1.8.0-openjdk-1.8.0.172-12.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jun 18 2018
java-1.8.0-openjdk-1.8.0.172-9.b11.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Jul 23 2018
java-1.8.0-openjdk-1.8.0.181-7.b13.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Sep 5 2018
java-1.8.0-openjdk-1.8.0.181.b15-0.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 4 2018
java-1.8.0-openjdk-1.8.0.181.b15-5.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc28.x86_64
drwxr-xr-x. 3 root root 4096 Oct 11 2018
java-1.8.0-openjdk-1.8.0.181.b15-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 29 2018
java-1.8.0-openjdk-1.8.0.191.b12-11.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Nov 1 2018
java-1.8.0-openjdk-1.8.0.191.b12-8.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Jan 14 2019
java-1.8.0-openjdk-1.8.0.191.b13-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Feb 6 2019
java-1.8.0-openjdk-1.8.0.201.b09-2.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Mar 26 2019
java-1.8.0-openjdk-1.8.0.201.b09-6.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc29.x86_64
drwxr-xr-x. 3 root root 4096 Apr 23 2019
java-1.8.0-openjdk-1.8.0.212.b04-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Jul 31 2019
java-1.8.0-openjdk-1.8.0.222.b10-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc30.x86_64
drwxr-xr-x. 3 root root 4096 Oct 16 2019
java-1.8.0-openjdk-1.8.0.232.b09-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Jan 28 2020
java-1.8.0-openjdk-1.8.0.242.b08-0.fc31.x86_64
drwxr-xr-x. 3 root root 4096 Mar 23 2020
java-1.8.0-openjdk-1.8.0.242.b08-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 4 2020
java-1.8.0-openjdk-1.8.0.252.b09-0.fc32.x86_64
drwxr-xr-x. 3 root root 4096 May 22 2020
java-1.8.0-openjdk-1.8.0.252.b09-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 17 2020
java-1.8.0-openjdk-1.8.0.262.b10-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Jul 28 2020
java-1.8.0-openjdk-1.8.0.265.b01-1.fc32.x86_64
drwxr-xr-x. 3 root root 4096 Oct 21 2020
java-1.8.0-openjdk-1.8.0.272.b10-0.fc32.x86_64
lrwxrwxrwx. 1 root root 21 Sep 10 14:32 jre -> /etc/alternatives/jre
lrwxrwxrwx. 1 root root 24 Sep 10 14:32 jre-11 -> /etc/alternatives/jre_11
lrwxrwxrwx. 1 root root 32 Sep 10 14:32 jre-11-openjdk ->
/etc/alternatives/jre_11_openjdk
lrwxrwxrwx. 1 root root 41 Aug 31 18:50
jre-11-openjdk-11.0.12.0.7-4.fc34.x86_64 ->
java-11-openjdk-11.0.12.0.7-4.fc34.x86_64
lrwxrwxrwx. 1 root root 29 Sep 10 14:32 jre-openjdk ->
/etc/alternatives/jre_openjdk
I think the OpenJDK's scriplets need to be adjusted to remove everything.
--
Sincerely,
Vitaly Zaitsev (vitaly(a)easycoding.org)
1 year, 11 months
RHEL moving to issues.redhat.com only long term
by Josh Boyer
Hi Fedora, CentOS, and EPEL Communities!
As part of our continued 3 year major Red Hat Enterprise Linux release
cadence, RHEL 9 development is starting to wrap up with the spring
2022 release coming soon. That means planning for the next release
will start in earnest in the very near future. As some of you may
know, Red Hat has been using both Bugzilla and Jira via
issues.redhat.com for RHEL development for several years. Our
intention is to move to using issues.redhat.com only for the major
RHEL releases after RHEL 9.
What does this mean for Fedora and CentOS? This discussion is in part
to figure that out. Based on some very brief analysis, the following
should hold:
- RHEL customers should continue to file support cases through the Red
Hat Customer portal, which will remain consistent regardless of the
backend tooling used.
- There is no imminent retirement of the Red Hat Bugzilla instance
being planned at this time. RHEL 7, 8, and 9 will continue to use
bugzilla in some form and RHEL 9 has a very long lifecycle.
- Fedora Linux and EPEL have their own Bugzilla product families and
are not directly impacted in their own workflows by the choice to use
only issues.redhat.com for RHEL.
- There will be impacts on existing documentation that provide
guidance on requesting things from RHEL in various places like EPEL.
We will be happy to help adjust these.
- CentOS Stream contribution and bug reporting workflows will be
adjusted to use issues.redhat.com instead of bugzilla in the relevant
places. This should apply to all versions of CentOS Stream for a
unified contributor workflow. This will happen gradually as we
discover the best workflow to use.
If there are other impacts that you can think of, please raise them on
this thread. We’d like to ensure we’re covering as much as possible
as this rolls out.
josh
1 year, 12 months
Uninitialized variables and F37
by Steve Grubb
Hello,
This is a continuation of the discussion from F36 Change: GNU Toolchain
Update.
Uninitialized variables are a big problem. They can be sources of information
exposure if parts of a buffer are not initialized. They can also cause
unexpected execution paths if the attacker can groom the memory to a value of
their choosing. If the variable is a pointer to heap, this can cause free to
corrupt memory under certain circumstances. If the uninitialized memory is
part of user input, this can lead to improper input validation. This is not
hypothetical. All of these come from a paper doing an emprical study of
android flaws. [1] The data used in the paper is here. [2]
Part of the problem is that compilers and static analysis tools can't always
find them. I created a test program that has 8 uses of unintialized variables.
Gcc 11 misses all of them. Gcc 12 finds 2. Clang 13 finds 1. cppcheck finds 2 or
3 - but does so much complaining you'd think it found all. Valgrind finds 2.
Flexelint, a commercial linter, finds 1.
Since tools can't always find them, the only option we have right now is force
initialization to something the attacker cannot control. Kees Cook started a
discussion on the llvm developers mail list a while back. He makes a very
clear argument. I would be repeating his points, so please read the original
discussion here (also read the replies):
https://lists.llvm.org/pipermail/cfe-dev/2020-April/065221.html
He talks about -ftrivial-auto-var-init=zero being used for production builds
and -ftrivial-auto-var-init=<pattern> being used for debug builds. The use
is not just the kernel. Consider a server that returns data across the
network to a client. It could possibly leak crypto keys or passwords if the
returned data structure has uninitialized memory.
For more background, the creator of this technology for LLVM presented a talk
about this feature at a past LLVM developer conference:
https://www.youtube.com/watch?v=I-XUHPimq3o
He said this would have prevented over 900 fixed CVE's in Chrome and 12% of
all Android CVE's.
From deep inside the LLVM thread above, comes this nugget:
---
To add in, we (Microsoft) currently use zero initialization technology in
Visual Studio in a large amount of production code we ship to customers (all
kernel components, a number of user-mode components). This code is both C and
C++.
We already have had multiple vulnerabilities killed because we shipped this
technology in production. We received bug reports with repros that worked on
older versions of Windows without the mitigation and new versions of Windows
that do have it. The new versions don't repro, the old ones do.
---
Microsoft is also digging in to uninitialized variables. They have a lengthy
blog post that talks about extending this to heap memory. [3]
I think this would be an important step forward to turn this on across all
compilations. We could wipe out an entire class of bugs in one fell swoop.
But then, what about heap allocations? Calloc has existed for a long time. It
might be worthwhile to have a CFLAG that can tell glibc (or other allocators)
to substitute something like calloc for malloc.
Cheers,
-Steve
[1] - https://picture.iczhiku.com/resource/paper/shkeTWJEaFUuWCMc.pdf
[2] - http://ml-papers.gitlab.io/android.vulnerabilities-2017/appendix/
MSR2017/vulnerabilitiesList.html
[3] - https://msrc-blog.microsoft.com/2020/07/02/solving-uninitialized-kernel-p...
2 years
Heads-up: grpc 1.41.0 coming to Rawhide with C (core) and C++ soname
bumps
by Ben Beasley
In one week (October 6), or slightly later, I will build grpc 1.41.0 for
Rawhide (F36). Fedora 35 will remain on 1.39.1.
As is traditional for minor releases of grpc, the C++ ABI was broken
(soversion bumped from 1.40 to 1.41). This time, the C (core) ABI was
also broken (soversion bumped from 18 to 19).
I will coordinate builds in a side tag of packages that use the C (core)
and/or C++ libraries. Maintainers of the following packages should have
received this email directly:
• bear
• frr
• perl-grpc-xs
Packages that use the Python bindings should be unaffected, as there
should be no incompatible API changes:
• buildstream
• python-chirpstack-api
• python-etcd3
• python-google-api-core
• python-google-cloud-core
• python-grpc-google-iam
• python-opencensus (orphaned)
• python-opencensus-proto
• python-opentelemetry
• python-pytest-grpc
• python-xds-protos
2 years
F37 Change: Enable read only /sysroot for Fedora Silverblue & Kinoite
(Self-Contained Change proposal)
by Ben Cotton
https://fedoraproject.org/wiki/Changes/Silverblue_Kinoite_readonly_sysroot
== Summary ==
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
== Owner ==
* Name: [[User:Siosm| Timothée Ravier]], [[User:Tpopela| Tomáš
Popela]], [[User:jkonecny| Jiří Konečný]]
* Email: siosm(a)fedoraproject.org, tpopela(a)fedoraproject.org, jkonecny(a)redhat.com
* FESCo shepherd: [[User:Ngompa| Neal Gompa]] ngompa(a)fedoraproject.org
== Detailed Description ==
On rpm-ostree based systems, the real root (the root directory of the
root partition on the disk) is mounted under the `/sysroot` path. By
default it contains the state of the system (the content of `var` and
`etc`) as well as the system versions themselves (each versioned copy
of `/usr`) in the ostree repository (`/ostree/repo`).
This change is about enabling an opt-in ostree feature that re-mounts
`/sysroot` as read only to avoid accidental changes.
Users and administrators are not expected to directly interact with
the content available there and should instead use the interface
offered by rpm-ostree, GNOME Software or (soon) Plasma Discover to
manage their system.
Example of issue: https://github.com/fedora-silverblue/issue-tracker/issues/232
This change replicates for Fedora Silverblue/Kinoite what has been
done in Fedora CoreOS in a previous release.
== Feedback ==
None so far.
== Benefit to Fedora ==
This will make Fedora Silverblue/Kinoite more robust to accidental
damage from users.
== Scope ==
* Proposal owners:
** Work on the changes requires for new installations (potentially
Anaconda configuration changes) and support for in place updates for
existing installations (requires a two step process).
* Other developers:
** Potential Anaconda changes required.
* Release engineering: N/A
* 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 ==
We will create a systemd unit that perform the updates in place for
existing systems. This will require a two step process (changing the
existing kernel arguments, and then enabling the ostree feature). Once
the feature is enabled, user won't be able to rollback to previous
deployments where the kernel argument is not set. We will have to
clearly document that in the documentation for easier troubleshooting.
== How To Test ==
Only try the following if you are confortable debugging an un-bootable
system and have made backups!
`$ sudo rpm-ostree kargs --append-if-missing=rw`
`$ sudo ostree config --repo=/sysroot/ostree/repo set "sysroot.readonly" "true"`
`$ sudo systemctl reboot`
Note that you can not "rollback" to the previous deployment to undo
this change. You will have to boot into a Live ISO and edit the config
file in the ostree repo to remove this config option.
== User Experience ==
There should be no visible change in user experience.
== Dependencies ==
Requires changes in Anaconda (maybe just config?) to set default kargs
and property on ostree repo for new installations.
== Contingency Plan ==
Revert the change before the release.
== Documentation ==
N/A (not a System Wide Change)
== Release Notes ==
TODO
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years
F36 Final blocker status summary
by Ben Cotton
F36 Beta is go, so it's time to shift to Final blockers. The Final
freeze begins on 5 April, with a target release date of 19 April.
Action summary
====================
Accepted blockers
-----------------
1. grub2 — Windows with bitlocker enabled can't be booted, needs to
use bootnext instead of chainloader — NEW
ACTION: Maintainers to determine if this can be supported in time for F36
2. gtk4 — gtk_widget_measure: assertion 'for_size >= -1' failed — VERIFIED
ACTION: none
3. mutter — The input string via Input Method isn't renderred properly
at the search box on Activities — ASSIGNED
ACTION: Upstream to diagnose and fix issue
4. nss-mdns — Require authselect for use in scriptlets — ON_QA
ACTION: QA to verify FEDORA-2022-09f077aa3a
5. plasma-discover — The About button sends Discover into loop and the
application stops responding. — NEW
ACTION: Upstream to diagnose and fix issue
Proposed blockers
-----------------
1. gnome-connections — [abrt] gnome-connections: _mid_memalign():
gnome-connections killed by SIGSEGV — NEW
ACTION: Maintainers to diagnose issue
2. gvfs — [abrt] gvfs: type_class_init_Wm(): gvfsd-dav killed by
SIGABRT — MODIFIED
ACTION: QA to verify FEDORA-2022-a69718b1e1
3. mutter — Workstation Live is frozen in a VM with QXL video driver
(Virtio works OK) — NEW
ACTION: Maintainers to diagnose issue
4. rpm — symlink /var/lib/rpm->/usr/lib/sysimage/rpm does not exist — ON_QA
ACTION: QA to verify FEDORA-2022-c564d315fc
5. tracker-miners — tracker-extract-3 killed by SIGSYS — NEW
ACTION: Maintainers to diagnose issue
6. xorg-x11-server — Basic graphics mode broken for KDE (BIOS/UEFI)
and GNOME (UEFI+X11) — NEW
ACTION: Maintainser to diagnose issue
Bug-by-bug detail
=============
Accepted blockers
-----------------
1. grub2 — https://bugzilla.redhat.com/show_bug.cgi?id=2049849 — NEW
Windows with bitlocker enabled can't be booted, needs to use bootnext
instead of chainloader
By default, dual-boot systems that use Bitlocker on Windows cannot
boot to Windows without prompting for the recovery key. There are
workarounds for this and it's not exactly a *bug* in grub.
2. gtk4 — https://bugzilla.redhat.com/show_bug.cgi?id=2043335 — VERIFIED
gtk_widget_measure: assertion 'for_size >= -1' failed
Searching for applications in Software resulted in a hang. Fixed in
gnome-software-42~beta-2.fc36.
3. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2062660 — ASSIGNED
The input string via Input Method isn't renderred properly at the
search box on Activities
Pre-edit strings are not rendered in some cases, only showing the
first keypress. Filed upstream as
https://gitlab.gnome.org/GNOME/mutter/-/issues/2188
4. nss-mdns — https://bugzilla.redhat.com/show_bug.cgi?id=2056927 — ON_QA
Require authselect for use in scriptlets
nss-mdns does not require authselect, which it uses in scriptlets.
This can result in the scriptlet failing. FEDORA-2022-09f077aa3a
contains a candidate fix.
5. plasma-discover — https://bugzilla.redhat.com/show_bug.cgi?id=2057563 — NEW
The About button sends Discover into loop and the application stops responding.
Clicking the About button causes a loop which renders Discover
unresponsive (except when the window is maximized).
Proposed blockers
-----------------
1. gnome-connections — https://bugzilla.redhat.com/show_bug.cgi?id=2068015 — NEW
[abrt] gnome-connections: _mid_memalign(): gnome-connections killed by SIGSEGV
Attempting to connect to an RDP server causes Connections to crash.
2. gvfs — https://bugzilla.redhat.com/show_bug.cgi?id=2066717 — MODIFIED
[abrt] gvfs: type_class_init_Wm(): gvfsd-dav killed by SIGABRT
Connecting to a DAV share on a remote F35 computer causes Nautilus to
crash. F35->F35 and F35->F36 work. FEDORA-2022-a69718b1e1 contains a
candidate fix.
3. mutter — https://bugzilla.redhat.com/show_bug.cgi?id=2063156 — NEW
Workstation Live is frozen in a VM with QXL video driver (Virtio works OK)
VMs that initially use the QXL driver appears frozen. Using virtio
(including to switching to QXL after?) avoids this. KDE Lives do not
display (heh) this behavior. There appears to still be a fair amount
of uncertainty about what exact conditions cause this.
4. rpm — https://bugzilla.redhat.com/show_bug.cgi?id=2066427 — ON_QA
symlink /var/lib/rpm->/usr/lib/sysimage/rpm does not exist
The symlink for RPM DB relocation did not exist on clean installs.
FEDORA-2022-c564d315fc contains a candidate fix.
5. tracker-miners — https://bugzilla.redhat.com/show_bug.cgi?id=2066703 — NEW
tracker-extract-3 killed by SIGSYS
In some cases, shortly after login, tracker-miners crashes. The crash
appears several (or 100+) times in abrt.
6. xorg-x11-server — https://bugzilla.redhat.com/show_bug.cgi?id=2067151 — NEW
Basic graphics mode broken for KDE (BIOS/UEFI) and GNOME (UEFI+X11)
Basic graphics mode in F36 KDE is broken universally. For GNOME, it is
broken, but only on X11+EFI. It is unclear if these are the same or
separate issues. All combinations work as expected in F35.
--
Ben Cotton
He / Him / His
Fedora Program Manager
Red Hat
TZ=America/Indiana/Indianapolis
2 years
Problem with SSL in Fedora 36
by José Abílio Matos
In one, and just one, of my email accounts the upgrade to F36 failed with
this:
The underlying socket is having troubles when processing connection to
imap.xxx.xx.xx:993: Error during SSL handshake: error:0A0C0103:SSL
routines::internal error
No email program works, I tried kmail, trojitá, thunderbird. The connection
fails immediatelly with the above error.
Where should I fill this report, under openssl?
Searching a bit this seems related to:
https://fedoraproject.org/wiki/Changes/OpenSSL3.0
Regards,
--
José Abílio
2 years
Landing a larger-than-release change (distrusting SHA-1 signatures)
by Alexander Sosedkin
Hello, community, I need your wisdom for planning a disruptive change.
Fedora 28 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings
Fedora 33 had https://fedoraproject.org/wiki/Changes/StrongCryptoSettings2
I believe we should start planning
for the next cryptographic defaults tightening.
And next time it's gonna be even more disruptive because of SHA-1 (again).
SHA-1 is a hash function from 1995,
which collision resistance is no longer to be relied upon for security [1].
At the same time, it's not like software has successfully migrated off it,
not even close.
It's not a question of "if" the world should migrate from it,
sooner or later we must part ways with it.
(Technically, some acute energy crisis or a collapse of civilization
forever raising the costs of computations thousandfold would also do,
but let's agree that migrating to a more modern hash is the way =)
We've been disabling it in TLS, but its usage is much wider than TLS.
The next agonizing step is to restrict its usage for signatures
on the cryptographic libraries level, with openssl being the scariest one.
Good news is, RHEL-9 is gonna lead the way
and thus will take a lot of the hits first.
Fedora doesn't have to pioneer it.
Bad news is, Fedora has to follow suit someday anyway,
and this brings me to how does one land such a change.
---
Fedora is a large distribution with short release cycles, and
the only realistic way to weed out its reliance on SHA-1 signatures
from all of its numerous dark corners is to break them.
Make creation and verification fail in default configuration.
But it's unreasonable to just wait for, say, Fedora 37 branch-off
and break it in Rawhide for Fedora 38.
The fallout will just be too big.
Maintainers need time to get bugs, look into them, think,
analyze, react and test --- and that's just if it fails correctly!
Unfortunately, it's not just that the error paths are as dusty as they get
because the program counter has never set foot on them before.
Some maintainers might even find that
picking a different hash function renders their code non-interoperable,
or even that protocols they implement have SHA-1 hardcoded in the spec.
Or that everything is ready, but real world deployments need another decade.
Or that on-disk formats are just hard to change and migrate.
Took git years to migrate from SHA-1, and some others haven't even started.
There are gonna be investigations, planning, exceptions, upstream changes,
opt-out mechanisms, arguing, compromises, waiting out, all kinds of things.
It's gonna be big. Too big for a single release cycle.
---
But how does one land something and give the distribution
the extra cycles needed to react? That's not really clear to me.
An obvious thing is to announce it in one cycle and land in another one.
The downsides are well-documented
in "The Hitchhiker's Guide to the Galaxy":
announcements are one weak measure, and then it's too late.
A second scheme I can come up with is a "jump scare".
Break the functionality in Fedora 37 Rawhide,
make most of the affected people realize the depth of the problem,
then unbreak it. Break again for Fedora 38 and never fix.
This could also be extended into "let one stable release slide'.
Break in 37 Rawhide, unbreak on branched off 37,
but never in Rawhide.
But these are all rather... crude?
Sure there should be better ways,
preferably something explored before.
I'm all for pulling this tooth out smoothly,
but I need hints on how to do it.
I hope that together we can devise a better plan than these.
So, how does one land a change that's bigger than a release cycle?
[1] https://eprint.iacr.org/2020/014
2 years
