+1

Note that backward compatibility is not generally an issue, but the older releases like the one we have in EPEL 9 right now actually has an issue with e.g. newer versions of the starship prompt, so updating is actually going to fix some functionality for users too

starship issue: in 3.5.x $(...) is not supported yet and Fish insists (...) is used - newer versions generally support more Bash-isms

❯ distrobox enter c9s
/tmp/.psub.R9VFUYhNNE (line 67): $(...) is not supported. In fish, please use '(commandline)'.
    if commandline --is-valid || test -z "$(commandline)" && not commandline --paging-mode
                                          ^
from sourcing file /tmp/.psub.R9VFUYhNNE
    called on line 1 of file -
from sourcing file -
    called on line 52 of file ~/.config/fish/config.fish
from sourcing file ~/.config/fish/config.fish
    called during startup
source: Error while reading file '/tmp/.psub.R9VFUYhNNE'

I took a closer look at the CVE in question to see if it's feasible to backport instead. I was able to cherry pick the commit that fixes it with some light adjustments, but it results in the testing suite failing. The error is rather cryptic.

Error: Test failed on line 5589: [string match -r \(\?=ab\\K\) ab]: expected return code 0 but got 2
Error: Test failed on line 5589: [string match -r \(\?=ab\\K\)..\(\?=cd\\K\) abcd]: expected return code 0 but got 2

I also tried backporting that commit with another commit that seemed to be related, but the test suite still fails. There may be some combination of commits that when backported together fix the CVE and give a working test suite run, but I'm ready to call this effort "non-trivial" and won't be spending any more time myself trying to get a functional backport.

If this CVE fix were easy to backport, I would vote -1 for a rebase. If this were not easy to backport and the CVE was rated higher, I would vote +1 for a rebase just for the security aspect. I'm kinda left on the fence, so for now I'll got with a 0 vote. I don't think compatibility with the latest starship versions is necessarily a good justification for a rebase.

Bubbling this for the meeting again, we need to decide one way or another.

If we don't approve the incompatible upgrade - what do we do with the Bugzilla issue? Keep it open but comment we can't fix it? Closing seems wrong.

Breaking changes:

3.6.0 - https://github.com/fish-shell/fish-shell/blob/master/CHANGELOG.rst#deprecations-and-removed-features-4

3.6.1 - https://github.com/fish-shell/fish-shell/blob/master/CHANGELOG.rst#deprecations-and-removed-features-3 (removes a feature that got broken in 3.6.0)

3.7.0 -https://github.com/fish-shell/fish-shell/blob/master/CHANGELOG.rst#deprecations-and-removed-features-2 - only not setting LS_COLORS by default, not a big deal

This is approved at today's meeting:

Proposal to upgrade fish in epel9 to the latest 3.x version has passed 3(+1) 0(-1) 3(0) with one not voted.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/epel/steering/issues/320

Please continue any further discussion there.