Re: git: cb350ba7bf7c - main - kerberos: Fix numerous segfaults when using weak crypto

From: Cy Schubert <Cy.Schubert_at_cschubert.com>
Date: Sat, 13 Jan 2024 14:19:53 UTC
In message <20240113141123.01FCD22B@slippy.cwsent.com>, Cy Schubert writes:
> In message <20240112074339.A581B23D@slippy.cwsent.com>, Cy Schubert writes:
> > In message <20240112071106.C72D8235@slippy.cwsent.com>, Cy Schubert writes:
> > > In message <CF222483-972B-4F25-93F6-EA3161AE2FCA@freebsd.org>, Jessica 
> > > Clarke w
> > > rites:
> > > > On 11 Jan 2024, at 13:31, Cy Schubert <cy@FreeBSD.org> wrote:
> > > > >=20
> > > > > The branch main has been updated by cy:
> > > > >=20
> > > > > URL: =
> > > > https://cgit.FreeBSD.org/src/commit/?id=3Dcb350ba7bf7ca7c4cb97ed2c20ab4
> 5a
> > f=
> > > > 60382cfb
> > > > >=20
> > > > > commit cb350ba7bf7ca7c4cb97ed2c20ab45af60382cfb
> > > > > Author:     Cy Schubert <cy@FreeBSD.org>
> > > > > AuthorDate: 2023-12-06 15:30:05 +0000
> > > > > Commit:     Cy Schubert <cy@FreeBSD.org>
> > > > > CommitDate: 2024-01-11 13:26:42 +0000
> > > > >=20
> > > > >    kerberos: Fix numerous segfaults when using weak crypto
> > > > >=20
> > > > >    Weak crypto is provided by the openssl legacy provider which is
> > > > >    not load by default. Load the legacy providers as needed.
> > > > >=20
> > > > >    When the legacy provider is loaded into the default context the =
> > > > default
> > > > >    provider will no longer be automatically loaded. Without the =
> > > > default
> > > > >    provider the various kerberos applicaions and functions will =
> > > > abort().
> > > >
> > > > Hi,
> > > > This has completely broken macOS and Linux cross-building. Please
> > > > either fix this quickly or, if unable to, revert until such time as you
> > > > can. Note that patches can be tested by creating a PR against the
> > > > GitHub mirror.
> > >
> > > Thanks for the heads up. I see the problem and am working on a fix.
> >
> > I think the correct approach would be to separate the new 
> > fbsd_ossl_provider_load() and unload functions into their own library 
> > (instead of libroken). This avoids the less desirable option of including 
> > bsd.cpu.mk in secure/lib/Makefile.common, which does build but could affect
>  
> > future work.
>
> The alternative approach also requires secure/lib/libcrypto (because of 
> libkrb5) being built during prebuild phase. Either way bsd.cpu.mk will need 
> to be included in the secure/lib/libcrypto/Makefile.common. Both of these 
> similar approaches, attempting to limit the change to local to Heimdal only 
> result in the same Linux MacOS failure. This leaves us with enabling legacy 
> (weak) crypto globally, like this:
>
> diff --git a/crypto/openssl/apps/openssl.cnf b/crypto/openssl/apps/openssl.c
> nf
> index 7996120cc67e..659c0b21abbd 100644
> --- a/crypto/openssl/apps/openssl.cnf
> +++ b/crypto/openssl/apps/openssl.cnf
> @@ -57,6 +57,7 @@ providers = provider_sect
>  # List of providers to load
>  [provider_sect]
>  default = default_sect
> +legacy = legacy_set
>  # The fips section name should match the section name inside the
>  # included fipsmodule.cnf.
>  # fips = fips_sect
> @@ -70,8 +71,10 @@ default = default_sect
>  # OpenSSL may not work correctly which could lead to significant system
>  # problems including inability to remotely access the system.
>  [default_sect]
> -# activate = 1
> +activate = 1
>  
> +[legacy_sect]
> +activate = 1
>  
>  ####################################################################
>  [ ca ]
>
> Would this be acceptable or would we prefer to add bsd.cpu.mk to 
> secure/libcrypto/Makefile.inc?

Adding so@freebsd.org.


-- 
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:  <cy@FreeBSD.org>   Web:  https://FreeBSD.org
NTP:           <cy@nwtime.org>    Web:  https://nwtime.org

			e^(i*pi)+1=0