Date: Mon, 15 Jan 2024 07:17:08 -0800 From: Gordon Tetlow <gordon@tetlows.org> To: Cy Schubert <Cy.Schubert@cschubert.com> Cc: Jessica Clarke <jrtc27@freebsd.org>, Cy Schubert <cy@FreeBSD.org>, "src-committers@freebsd.org" <src-committers@FreeBSD.org>, "dev-commits-src-all@freebsd.org" <dev-commits-src-all@FreeBSD.org>, "dev-commits-src-main@freebsd.org" <dev-commits-src-main@FreeBSD.org>, FreeBSD Security Officer <so@freebsd.org> Subject: Re: git: cb350ba7bf7c - main - kerberos: Fix numerous segfaults when using weak crypto Message-ID: <75357052-F1AF-4E48-B2A8-5FE23EFB2B54@tetlows.org> In-Reply-To: <20240113141953.E79B716E@slippy.cwsent.com> References: <202401111331.40BDVZfn015429@gitrepo.freebsd.org> <CF222483-972B-4F25-93F6-EA3161AE2FCA@freebsd.org> <20240112071106.C72D8235@slippy.cwsent.com> <20240112074339.A581B23D@slippy.cwsent.com> <20240113141123.01FCD22B@slippy.cwsent.com> <20240113141953.E79B716E@slippy.cwsent.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?75357052-F1AF-4E48-B2A8-5FE23EFB2B54>