Dear Alexander, On Wed, Mar 18, 2026 at 3:09 PM Solar Designer <[email protected]> wrote:
> Hi Dmitry, > > On Wed, Mar 18, 2026 at 09:14:31AM +0100, Dmitry Belyavskiy wrote: > > Can we somehow establish some better coordination in case of widely used > > downstream patches, especially for such an important, ubiquitous and > > heavily patched component as OpenSSH? > > This was brought to the distros list on March 5. On March 6, I wrote: > > "Looks like Red Hat packages are also affected. In particular, I looked > at openssh-8.0p1-gssapi-keyex.patch from RHEL 9." > > so it's not like Red Hat could assume this was limited to Debian/Ubuntu. > > I now recall that something similar happened on a previous occasion, > where you were not aware of a relevant issue until public disclosure. > > So we seem to have a question to the Red Hat security team here - are > you going to be informing your package maintainers of embargoed issues > (which I consider fitting the need-to-know condition of the distros > list), or are you deliberately handling them differently, or neither? > Thanks, I will investigate it. > > I suppose this could reasonably vary by package - security updates to be > prepared by security team vs. by package maintainer. > > Should I be taking care of notifying Dmitry for OpenSSH specifically, > where we know that he's eager to prepare for these disclosures but is > often left out of the loop? IIRC, from the previous occasion I actually > planned to start doing that, but I forgot, I'm sorry. > No problem, thank you! I think OpenSSH, being heavily patched, deserves some special procedure, and can invite you to the discussion, if you are interested. Meanwhile, I see the Mitigation section in > https://access.redhat.com/security/cve/cve-2026-3497 has been updated to > correctly refer to GSSAPI key exchange rather than authentication, but > it still seems to imply the default configuration is affected - which I > think it is not, or is it? > I don't think so; I'll double-check. > > I wasn't too concerned about this issue for the Rocky Linux SIG/Security > package that I maintain because we build it without Kerberos and GSSAPI > support since March 2024. The patch is still applied, but the > GSSAPIKeyExchange setting does not exist for real (is silently ignored > via an extra patch for compatibility with FIPS configs that disable it), > so it can't possibly be enabled there. Ditto in CIQ's RLC Pro Hardened. > Thank you very much! -- Dmitry Belyavskiy
