FIPS compliance efforts in Fedora and RHEL
dbelyavs at redhat.com
Thu Apr 20 05:50:29 AEST 2023
On Wed, Apr 19, 2023 at 10:01 AM Dmitry Belyavskiy <dbelyavs at redhat.com> wrote:
> Dear Damien,
> On Wed, Apr 19, 2023 at 9:55 AM Damien Miller <djm at mindrot.org> wrote:
> > On Wed, 19 Apr 2023, Dmitry Belyavskiy wrote:
> > > > While I'm sure this is good for RHEL/rawhide users who care about FIPS,
> > > > Portable OpenSSH won't be able to merge this. We explictly aim to support
> > > > LibreSSL's libcrypto as well as openssl-1.1.x and neither supports the
> > > > OSSL_PARAM_BLD API (neither does BoringSSL, though our support for that
> > > > I'd describe as "best effort").
> > > >
> > > > If this changes we can look again.
> > >
> > > Yes, we understand and respect your choice.
> > > Would it be acceptable in any form being wrapped in necessary #ifdefs ?
> > No, I think it would be too intrusive.
> > IMO if we have to support both the new API and the libressl/1.1.1 API
> > then the only likely acceptable way would be to reimplement the new
> > API using the old, similar to what we did when moving to the OpenSSL
> > 1.1.x opaque structs while still supporting the 1.0.x API.
> > I have no idea whether this is even possible, and we wouldn't have the
> > luxury of being able to use OpenSSL code to do it (as we did last time)
> > as the license has changed to one that we don't want to accept in the
> > OpenSSH codebase.
> I think it's doable if libressl has 1.1.1-style EVP API. It is
> possible to assign RSA/EC/DH to EVP_PKEY object and use EVP API
> afterwards in 1.1.1 and use the OSSL_PARAM_BLD for 3.0
Will the patch providing compat layer in style
and making the crypto operations using EVP API in main files be acceptable?
More information about the openssh-unix-dev