Hi all,
There have been a number of releases of dav1d newer than the one shipped in EPEL 9 right now, one of which include fixes for this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2264940
Looking at upstream commit history, there seem to be other "security fixes" that have just not been assigned a CVE number. I have looked into backporting the fixes to the version currently in EPEL 9, but it's 1) unclear which commits all need to be backported, and 2) some changes aren't cleanly backportable, and 3) that would not cover security fixes not associated with a CVE number.
For this reason, I would like to build the version of dav1d that's currently in Fedora 40+ and in EPEL 10 also for EPEL 9. This includes one soname bump (since dav1d 1.3.0) due to an ABI change, which makes this an incompatible update, but there were no actual API changes.
Packages in the EPEL 9 repos that depend on dav1d that would need to be rebuilt:
chromium: chromium chromium: chromium-headless ffmpeg: libavcodec-free libavif0.10: libavif0.10 libavif: libavif libheif: libheif vlc: vlc-plugins-base xine-lib: xine-lib
Fabio
On Mon, Oct 21, 2024 at 8:04 AM Fabio Valentini decathorpe@gmail.com wrote:
Hi all,
There have been a number of releases of dav1d newer than the one shipped in EPEL 9 right now, one of which include fixes for this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2264940
Looking at upstream commit history, there seem to be other "security fixes" that have just not been assigned a CVE number. I have looked into backporting the fixes to the version currently in EPEL 9, but it's 1) unclear which commits all need to be backported, and 2) some changes aren't cleanly backportable, and 3) that would not cover security fixes not associated with a CVE number.
For this reason, I would like to build the version of dav1d that's currently in Fedora 40+ and in EPEL 10 also for EPEL 9. This includes one soname bump (since dav1d 1.3.0) due to an ABI change, which makes this an incompatible update, but there were no actual API changes.
Packages in the EPEL 9 repos that depend on dav1d that would need to be rebuilt:
chromium: chromium chromium: chromium-headless ffmpeg: libavcodec-free libavif0.10: libavif0.10 libavif: libavif libheif: libheif vlc: vlc-plugins-base xine-lib: xine-lib
Fabio
Thank you for following the Incompatible update process.
Looking at things, I agree that updating is the best step forward.
My only concern is that you will be rebuilding the "heavy hitters" dealing with web browsing, video and sound. If this gets approved, please be careful with those and try to communicate with their maintainers as much as possible.
Troy
On Mon, Oct 21, 2024 at 8:49 AM Troy Dawson tdawson@redhat.com wrote:
On Mon, Oct 21, 2024 at 8:04 AM Fabio Valentini decathorpe@gmail.com wrote:
Hi all,
There have been a number of releases of dav1d newer than the one shipped in EPEL 9 right now, one of which include fixes for this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2264940
Looking at upstream commit history, there seem to be other "security fixes" that have just not been assigned a CVE number. I have looked into backporting the fixes to the version currently in EPEL 9, but it's 1) unclear which commits all need to be backported, and 2) some changes aren't cleanly backportable, and 3) that would not cover security fixes not associated with a CVE number.
For this reason, I would like to build the version of dav1d that's currently in Fedora 40+ and in EPEL 10 also for EPEL 9. This includes one soname bump (since dav1d 1.3.0) due to an ABI change, which makes this an incompatible update, but there were no actual API changes.
Packages in the EPEL 9 repos that depend on dav1d that would need to be rebuilt:
chromium: chromium chromium: chromium-headless ffmpeg: libavcodec-free libavif0.10: libavif0.10 libavif: libavif libheif: libheif vlc: vlc-plugins-base xine-lib: xine-lib
Fabio
Thank you for following the Incompatible update process.
Looking at things, I agree that updating is the best step forward.
My only concern is that you will be rebuilding the "heavy hitters" dealing with web browsing, video and sound. If this gets approved, please be careful with those and try to communicate with their maintainers as much as possible.
Troy
This was brought up and approved at this weeks EPEL Steering Committee meeting. You may now proceed with the next steps in the Incompatible Upgrade process.
Troy
On Wed, Oct 30, 2024 at 8:53 PM Troy Dawson tdawson@redhat.com wrote:
On Mon, Oct 21, 2024 at 8:49 AM Troy Dawson tdawson@redhat.com wrote:
On Mon, Oct 21, 2024 at 8:04 AM Fabio Valentini decathorpe@gmail.com wrote:
Hi all,
There have been a number of releases of dav1d newer than the one shipped in EPEL 9 right now, one of which include fixes for this CVE: https://bugzilla.redhat.com/show_bug.cgi?id=2264940
Looking at upstream commit history, there seem to be other "security fixes" that have just not been assigned a CVE number. I have looked into backporting the fixes to the version currently in EPEL 9, but it's 1) unclear which commits all need to be backported, and 2) some changes aren't cleanly backportable, and 3) that would not cover security fixes not associated with a CVE number.
For this reason, I would like to build the version of dav1d that's currently in Fedora 40+ and in EPEL 10 also for EPEL 9. This includes one soname bump (since dav1d 1.3.0) due to an ABI change, which makes this an incompatible update, but there were no actual API changes.
Packages in the EPEL 9 repos that depend on dav1d that would need to be rebuilt:
chromium: chromium chromium: chromium-headless ffmpeg: libavcodec-free libavif0.10: libavif0.10 libavif: libavif libheif: libheif vlc: vlc-plugins-base xine-lib: xine-lib
Fabio
Thank you for following the Incompatible update process.
Looking at things, I agree that updating is the best step forward.
My only concern is that you will be rebuilding the "heavy hitters" dealing with web browsing, video and sound. If this gets approved, please be careful with those and try to communicate with their maintainers as much as possible.
Troy
This was brought up and approved at this weeks EPEL Steering Committee meeting. You may now proceed with the next steps in the Incompatible Upgrade process.
Thank you - I am starting to build things now, in epel9-build-side-99744.
Fabio
Hi,
While this seems to be ok for EPEL 9 (x86-64-v2), please note that jumping to dav1d 1.5.0 for Fedora still on generic x86-64 might hurt performance:
WARNING: we removed some of the SSE2 optimizations, so if you care about systems without SSSE3, you should be careful when updating!
Miloš
On Tue, Oct 22, 2024 at 1:37 PM Miloš Komarčević kmilos@gmail.com wrote:
Hi,
While this seems to be ok for EPEL 9 (x86-64-v2), please note that jumping to dav1d 1.5.0 for Fedora still on generic x86-64 might hurt performance:
WARNING: we removed some of the SSE2 optimizations, so if you care about systems without SSSE3, you should be careful when updating!
Yes, I've seen this warning. The package is already at 1.5.0 in Fedora though (not updated by me).
Also, SSE2 is already baseline for Fedora since forever, see also these notes on the relevant Change Proposal for Fedora 29: https://fedoraproject.org/wiki/Changes/Update_i686_architectural_baseline_to...
Fabio
On Tue, Oct 22, 2024 at 2:50 PM Miloš Komarčević kmilos@gmail.com wrote:
Fabio Valentini wrote:
Also, SSE2 is already baseline for Fedora since forever
The problem is that dav1d 1.5.0 _removed_ SSE2 optimizations from their code base, and now relies on SSSE3, which Fedora doesn't have, x86-64-v2 baseline is needed for that (which EPEL 9 has).
*sigh* you are correct. Looks like I need more coffee. The package should still be in compliance with all our policies and guidelines though, since dav1d 1.5.0 still doesn't *mandate* SSSE3, as far as I can tell.
Fabio
Ok, I see now there is runtime CPU detection in dav1d so only a (small?) portion of Fedora users w/ very old CPUs are affected by the update.
Miloš
epel-devel@lists.fedoraproject.org
-
Fabio Valentini -
Miloš Komarčević -
Troy Dawson