Re: OpenSSH GSSAPI keyex patch issue

[Dmitry Belyavskiy <dbelyavs () redhat com>]

Dear Alexander,

On Wed, Mar 18, 2026 at 3:09 PM Solar Designer <solar () openwall com> 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