Re: git: cb350ba7bf7c - main - kerberos: Fix numerous segfaults when using weak crypto
Date: Mon, 15 Jan 2024 15:17:08 UTC
> On Jan 13, 2024, at 6:19 AM, Cy Schubert <Cy.Schubert@cschubert.com> wrote: > > In message <20240113141123.01FCD22B@slippy.cwsent.com>, Cy Schubert writes: >> In message <20240112074339.A581B23D@slippy.cwsent.com>, Cy Schubert writes: >>> >>> 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. 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’s find a different path please. Best, Gordon Hat: security-officer.