> cleanup_exit() was not meant to be called from a signal handler [...] Fedora 38+ has moved to newer upstream OpenSSH that doesn't have the problematic cleanup_exit() call.

> This extra problematic logic only existed in upstream OpenSSH(-portable) for ~9 months

The fix also doesn't touch the Red Hat-specific code:

     diff -urp openssh-8.7p1-38.el9_4.1-tree.orig/sshd.c openssh-8.7p1-38.el9_4.1-tree/sshd.c
     --- openssh-8.7p1-38.el9_4.1-tree.orig/sshd.c 2024-07-08 03:42:51.431994307 +0200
     +++ openssh-8.7p1-38.el9_4.1-tree/sshd.c 2024-07-08 03:48:13.860316451 +0200
     @@ -384,7 +384,7 @@ grace_alarm_handler(int sig)
      
       /* Log error and exit. */
       if (use_privsep && pmonitor != NULL && pmonitor->m_pid <= 0)
     -  cleanup_exit(255); /* don't log in privsep child */
     +  _exit(1); /* don't log in privsep child */
       else {
        sigdie("Timeout before authentication for %s port %d",
            ssh_remote_ipaddr(the_active_state),

Cert's SIG30 rule page has a list: https://wiki.sei.cmu.edu/confluence/display/c/SIG30-C.+Call+...

Also there's https://clang.llvm.org/extra/clang-tidy/checks/bugprone/sign...

Ultimately it's an example of an invariant where it's clear that programmers can't be trusted to uphold it. In this case, the consequences can be very significant.

There is no portable way to annotate all functions ever written or ever will be written as being async signal safe.

Which functions are async signal safe varies with the operating system and runtime (eg. an unsafe function in linux-gnu might be safe in linux-musl or linux-bionic).

Other than those insurmountable problems, yeah, good idea.

They go for it because it gives a very stable, solid foundation. They don't want a fragile base layer prone to breaking every day of the week.

This involves backporting a lot of stuff (primarily security fixes) because you can't just upgrade any package to its latest version, it will have entirely new dependencies, potentially breaking changes etc.

What should RedHat do, which does not:

1) make them lose their enterprise customers wanting a stable base

2) have unpatched security holes all over their distros

3) not cause them to backport stuff (we are here at the moment) ?

Upstreams generally don't do this until prompted, and sometimes resist until the path is proven and becomes best practice because distributions pushed it.

This process is mostly invisible to you because distributions have been successful at getting the changes needed for sane and consistent behaviour embedded into tools and expectations by default. All you see are the patches that are in flight or didn't make it.

If you want a distribution that does only minimal patching then there are distributions for that. The fact that the major distributions do patch speaks volumes about which approach results in a better experience for users.

Also affected: Fedora 37, 36 and possibly 35, which are all end-of-life (since December 2023 in the case of Fedora 37).

Not affected: Fedora 38 (also EOL), 39 (maintained) and 40 (current).