openssh unix dev - Apr 2023 - FIPS compliance efforts in Fedora and RHEL

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.

-d

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

-- 
Dmitry Belyavskiy