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

In message <75357052-F1AF-4E48-B2A8-5FE23EFB2B54@tetlows.org>, Gordon 
Tetlow wr
ites:
> 
>
> > On Jan 13, 2024, at 6:19 AM, Cy Schubert <Cy.Schubert@cschubert.com> =
> wrote:
> >=20
> > In message <20240113141123.01FCD22B@slippy.cwsent.com>, Cy Schubert =
> writes:
> >> In message <20240112074339.A581B23D@slippy.cwsent.com>, Cy Schubert =
> writes:
> >>>=20
> >>> I think the correct approach would be to separate the new=20
> >>> fbsd_ossl_provider_load() and unload functions into their own =
> library=20
> >>> (instead of libroken). This avoids the less desirable option of =
> including=20
> >>> bsd.cpu.mk in secure/lib/Makefile.common, which does build but could =
> affect
> >>=20
> >>> future work.
> >>=20
> >> The alternative approach also requires secure/lib/libcrypto (because =
> of=20
> >> libkrb5) being built during prebuild phase. Either way bsd.cpu.mk =
> will need=20
> >> to be included in the secure/lib/libcrypto/Makefile.common. Both of =
> these=20
> >> similar approaches, attempting to limit the change to local to =
> Heimdal only=20
> >> result in the same Linux MacOS failure. This leaves us with enabling =
> legacy=20
> >> (weak) crypto globally, like this:
> >>=20
> >> 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 =3D provider_sect
> >> # List of providers to load
> >> [provider_sect]
> >> default =3D default_sect
> >> +legacy =3D legacy_set
> >> # The fips section name should match the section name inside the
> >> # included fipsmodule.cnf.
> >> # fips =3D fips_sect
> >> @@ -70,8 +71,10 @@ default =3D default_sect
> >> # OpenSSL may not work correctly which could lead to significant =
> system
> >> # problems including inability to remotely access the system.
> >> [default_sect]
> >> -# activate =3D 1
> >> +activate =3D 1
> >>=20
> >> +[legacy_sect]
> >> +activate =3D 1
> >>=20
> >> ####################################################################
> >> [ ca ]
> >>=20
> >> Would this be acceptable or would we prefer to add bsd.cpu.mk to=20
> >> secure/libcrypto/Makefile.inc?
> >=20
> > Adding so@freebsd.org.
>
> Globally enabling weak crypto to serve the needs of a cross-building =
> issue in software that less than 1% users use is a bad idea. Let=E2=80=99s=
>  find a different path please.
>
> Best,
> Gordon
> Hat: security-officer.=

I have another solution, being worked on. It will dlopen()/dlsym(). 
Unorthodox but should work around the Linux and MacOS issues. I'll create a 
GH PR (gotta love reusing and recycling acronyms) to test build on Linux as 
jrtc27 suggested, so please, nobody take the PR and commit it.

As it uses dlopen()/dlsym() it does not touch Makefile.inc1 nor 
src.libnames.mk, so it should build everywhere.

I don't use weak crypto here (with my MIT KDC). I'll ask those watching the 
bugzilla PR (gotta love recycling acronyms again) to test the new patch.


-- 
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