From nobody Mon Jan 15 15:17:08 2024 X-Original-To: dev-commits-src-all@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4TDG3s64YKz578tp for ; Mon, 15 Jan 2024 15:18:01 +0000 (UTC) (envelope-from gordon@tetlows.org) Received: from mr85p00im-ztdg06011901.me.com (mr85p00im-ztdg06011901.me.com [17.58.23.198]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4TDG3s0zVDz4r8q for ; Mon, 15 Jan 2024 15:18:01 +0000 (UTC) (envelope-from gordon@tetlows.org) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=tetlows.org header.s=sig1 header.b="hX/rWFP7"; dmarc=pass (policy=quarantine) header.from=tetlows.org; spf=pass (mx1.freebsd.org: domain of gordon@tetlows.org designates 17.58.23.198 as permitted sender) smtp.mailfrom=gordon@tetlows.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tetlows.org; s=sig1; t=1705331842; bh=rzyhz+tqBHmKeHIV8m6+jKLOAwG/levWiLJtjJmKGCg=; h=Content-Type:Mime-Version:Subject:From:Date:Message-Id:To; b=hX/rWFP7muEy4I1ntHbm59nnPJipmczhU5aancfLXNLNGTnwHqsd1L4gkMHtq0kN7 wUJKdKBMEloUKyKnc3eQR9HtOu8wUk1d0yKmtFHht2EArtI/p+Muu7Zz9KcmxlB4VX iUZizjdE7uqddwsT5dBcHK8zN8MX+IK1uuC+O96zZx1lGJIwTLOdDJ3Bw0i53CR0JE XJvcwM5S6K81nYXjN8+rHkWCqlYFsyeqryhpdpNxb+yulSpJ7/vcOXvS98f19Rr5rN 2h2MdYhyA8Y0mJEZBsLXy1cWnAqF0X9yVIjxg5fyhrULfMWNnyuhUwEicRizK0T7D9 Gk2czfjf8/6Lg== Received: from smtpclient.apple (mr38p00im-dlb-asmtp-mailmevip.me.com [17.57.152.18]) by mr85p00im-ztdg06011901.me.com (Postfix) with ESMTPSA id A8AEE90048F; Mon, 15 Jan 2024 15:17:20 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Commit messages for all branches of the src repository List-Archive: https://lists.freebsd.org/archives/dev-commits-src-all List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-dev-commits-src-all@freebsd.org X-BeenThere: dev-commits-src-all@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.700.6\)) Subject: Re: git: cb350ba7bf7c - main - kerberos: Fix numerous segfaults when using weak crypto From: Gordon Tetlow In-Reply-To: <20240113141953.E79B716E@slippy.cwsent.com> Date: Mon, 15 Jan 2024 07:17:08 -0800 Cc: Jessica Clarke , Cy Schubert , "src-committers@freebsd.org" , "dev-commits-src-all@freebsd.org" , "dev-commits-src-main@freebsd.org" , FreeBSD Security Officer Content-Transfer-Encoding: quoted-printable Message-Id: <75357052-F1AF-4E48-B2A8-5FE23EFB2B54@tetlows.org> References: <202401111331.40BDVZfn015429@gitrepo.freebsd.org> <20240112071106.C72D8235@slippy.cwsent.com> <20240112074339.A581B23D@slippy.cwsent.com> <20240113141123.01FCD22B@slippy.cwsent.com> <20240113141953.E79B716E@slippy.cwsent.com> To: Cy Schubert X-Mailer: Apple Mail (2.3731.700.6) X-Proofpoint-GUID: CuTlx4CXOrMhjd0aAaSI8eTVx51CwUEM X-Proofpoint-ORIG-GUID: CuTlx4CXOrMhjd0aAaSI8eTVx51CwUEM X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.272,Aquarius:18.0.997,Hydra:6.0.619,FMLib:17.11.176.26 definitions=2024-01-15_10,2024-01-15_03,2023-05-22_02 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 malwarescore=0 mlxlogscore=999 phishscore=0 clxscore=1030 spamscore=0 bulkscore=0 suspectscore=0 adultscore=0 mlxscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.19.0-2308100000 definitions=main-2401150111 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.20 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[tetlows.org,quarantine]; RWL_MAILSPIKE_VERYGOOD(-0.20)[17.58.23.198:from]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; R_DKIM_ALLOW(-0.20)[tetlows.org:s=sig1]; MIME_GOOD(-0.10)[text/plain]; ONCE_RECEIVED(0.10)[]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.198:from]; FROM_HAS_DN(0.00)[]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[tetlows.org:+]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_COUNT_ONE(0.00)[1]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; MIME_TRACE(0.00)[0:+]; MLMMJ_DEST(0.00)[dev-commits-src-all@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; FREEFALL_USER(0.00)[gordon]; MID_RHS_MATCH_FROM(0.00)[]; APPLE_MAILER_COMMON(0.00)[]; RCPT_COUNT_SEVEN(0.00)[7]; RCVD_VIA_SMTP_AUTH(0.00)[]; TO_DN_SOME(0.00)[] X-Rspamd-Queue-Id: 4TDG3s0zVDz4r8q > On Jan 13, 2024, at 6:19 AM, Cy Schubert = 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.=