[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAOcQRVUSSouoKX9-La7TBOYkySUbvZiQAjk1WOggu6Pw4D_mVA@mail.gmail.com>
Date: Wed, 18 Mar 2026 15:35:52 +0100
From: Dmitry Belyavskiy <dbelyavs@...hat.com>
To: oss-security@...ts.openwall.com
Subject: Re: OpenSSH GSSAPI keyex patch issue
Dear Alexander,
On Wed, Mar 18, 2026 at 3:09 PM Solar Designer <solar@...nwall.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
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
