From nobody Tue Apr 25 10:30:16 2023 X-Original-To: freebsd-arch@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 4Q5JDS15vWz470hf for ; Tue, 25 Apr 2023 10:30:32 +0000 (UTC) (envelope-from Alexander@leidinger.net) Received: from mailgate.Leidinger.net (mailgate.leidinger.net [IPv6:2a00:1828:2000:313::1:5]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q5JDR3XSJz41C3 for ; Tue, 25 Apr 2023 10:30:31 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; none Date: Tue, 25 Apr 2023 12:30:16 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1682418618; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=zpP7gPYWyPQHjDO5s/WET9cK5D3YzeG0CLfmGYiNr5A=; b=exh+8WuElUVzjBeIpmBX0MTb3OpQ7GjvEzzVj5eqVJ6vDFjuAGSoaqBFPwdx38/sqWTXjt ozLuu1f4ApXp/M7E1fbVuFUYjXyjsGcrqZccQ7cFwECs5WtA3BfSQqPA+IAtvHXDi5eHCw 0dQz720cAGpedl5UNp3/P4AplOmD39uqzXKeg09+bQSRAwSsQ33pL7w41L1ch+dgHXoudS TIBLJNlq/l3wZX6a6IFBICw+vD/AO/EbGMuIAhOPXvhrYwRihWfIXspW699TL7FW0w1AFN tqscuoL5/i8ny2DkuW8lPMVnSMtCansFWRWPE1afK+traKkfMBZl+6TF8GXmTA== Message-ID: <20230425123016.Horde.YqdbqxIwT9cc_qCUq1zhsfj@webmail.leidinger.net> From: Alexander Leidinger To: Charlie Li Cc: Ed Maste , Joerg Pulz , freebsd-arch Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> In-Reply-To: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> Accept-Language: de,en Content-Type: multipart/signed; boundary="=_2534iIRQQ2aqQWEes438_4Z"; protocol="application/pgp-signature"; micalg=pgp-sha256 List-Id: Discussion related to FreeBSD architecture List-Archive: https://lists.freebsd.org/archives/freebsd-arch List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arch@freebsd.org MIME-Version: 1.0 X-Rspamd-Queue-Id: 4Q5JDR3XSJz41C3 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:34240, ipnet:2a00:1828::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N This message is in MIME format and has been PGP signed. --=_2534iIRQQ2aqQWEes438_4Z Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Charlie Li (from Mon, 24 Apr 2023=20=20 10:33:39=20-0400): > Ed Maste wrote: >> The problem is that we have conflicting constraints: OpenSSL 1.1.1 is >> EOL shortly after 14.0 releases, and there are ports that do not yet >> build against OpenSSL 3. I am not sure how much will be broken if we >> update the base system to OpenSSL 3 but leave the privatelib aside >> (i.e., have the base system provide OpenSSL 3 to ports). >> > OpenSSL 3 is a major, even larger than 1.1, API/ABI change. Quite a=20=20 >=20bit of stuff will be broken today. The effort here has to include=20=20 >=20working with as many port upstreams as possible to force the issue,=20= =20 >=20as they may not hold OpenSSL 3 compatibility to be an immediate=20=20 >=20priority; patching ports on a large scale like this is not=20=20 >=20sustainable. OpenSSL is a major part of the security infrastructure worldwide. Once=20= =20 1.1.1=20is EOL, it is "burnt" and should not be used anymore. Any 0-day=20= =20 exploit=20will cause havoc and software would need to be switched to 3.x=20= =20 before=20that if you take it seriously. So from a security perspective, I rather switch now (while 14.0 is=20=20 still=20called -current instead of -rc or -stable) to 3.x and live with=20= =20 the=20collateral damage in ports, which will naturally get smaller over=20= =20 time=20as people have more pressure to fix it soon to get something they=20= =20 need=20get up and running. From a stability point of view, this is off course a bad way of handling i= t. As -current is not -stable, I could imagine a split view on this: - announce to -stable users to switch to the quarterly branch for a while - warn -current users about collateral damage for a while (e.g.=20=20 UPDATING=20entry in src and ports) - switch -current to 3.x (quick and easy, not as a private lib) - let port maintainers and users work together on fixes for the=20=20 broken=20ports (in each port: if OSVERSION >=3D 14000x use 3.x patch) ... - ... while work is underway to switch openssl to a private lib in -curre= nt. Maybe also halt the package distribution to the official download=20=20 sites=20while the main branch of the ports tree has too much collateral=20= =20 damage,=20and resume it once "enough" ports build. That's maybe not nice, but at least something which a volunteer=20=20 project=20is able to handle. It divides the problem into smaller pieces=20= =20 which=20can be worked on in parallel. For 13-stable I consider the train to have already left the station.=20=20 We=20can not fix existing releases to use openssl 3.x in parallel to the=20= =20 existing=201.1.1 libs. Anything we do to ports to use openssl 3.x, no=20=20 matter=20if as a private lib in base or not, has to be gated with=20=20 OSVERSION=20conditionals. As such 13.x is a train wreck from a security=20= =20 perspective=20as soon as openssl is EOL and IMO we need to highlight in=20= =20 the=20release notes in 14.0 that it is highly recommended to switch to=20= =20 it=20as soon as possible. My main point is, that we can not only look at 14.0, but we need to=20=20 have=20a look at the big picture, including 13.x and the global security=20= =20 implications.=20And from my point of view, we (as a volunteer effort)=20=20 are=20not able to deliver a solution which works for the entire big=20=20 picture.=20We have to accept some kind of collateral damage in the big=20= =20 picture.=20And my suggestion is to think about which collateral damage=20= =20 we=20are willing to accept. The above is one way of accepting a=20=20 particular=20collateral damage. There are other scenarious which have=20=20 different=20kinds of collateral damage, and as a project we need to=20=20 decide=20which one we are willing to accept, we need to realistically=20=20 think=20about which one we able to work on (and personally I would value=20= =20 the=20voice of those people which will provide a halping hand a bit=20=20 higher=20than the opinion of others). I agree that ideally all upstreams have to be included, but if we are=20=20 realistic,=20it means we fix our stuff and provide patches to upstream,=20= =20 and=20some of those may even be included upstream (yes, there are off=20=20 course=20also upstreams which will do the right thing, but we can not=20=20 depend=20on this on a global scale). Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_2534iIRQQ2aqQWEes438_4Z Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmRHq7cACgkQEg2wmwP4 2Ib12w//V6dYneaon4zzNuPcCrfrjp605qjVCnwWEJizj2g9kPX9LzaTMOgHQNZp Xpw8ev8qHu6YWh9ssTwkIXmbzFXeGXB9oFcZrzbBcjt0LSEeY6I5ZaQlqwrmVgfo VilZ+bUaEZHASp8LtbVX2fJzF+aGrdPzvjEhPLmBDZNsQYImv33o6jkmfHKdD06k VMmoKViaJUYy+5JMkOlk12f3U0m/QLQQFsgbRzCBHgfe98r3XXEJLfmiOSH/POyU 1RvrlZZ29ZocRlyDZUkbZNnpBO9uQTIxETN7BIpmbnTSrxYtFq4pA0Q7yCnA83kf oJ7odK/UAZktrjlzfOUIJ0/0Q7+osGzphy9/AIMFXnGfNeswIouEYHVipG3LVLjh 7nVMiM7YY24YKhH57ZsYkjIN4BGU+nn0mIbTl6AQQD+Gv9H9rf8hc1r7NlPirijp HcJeqbfH+uJO5yUY3JlhxVBHnRxclSPxsp59yR6LcZ07COGQTMMr799ajL+qx0Aw /zx+nIXw341rCECEqveNthKXHN32w7R67bg6l4nUiPYUWP+33z3PCACAJV97JViv BEVePBav31i7cok0pcDdacBgx9CMbMxUAQYc5smqlba7RLvrl5VCB8/jVj9mYX9Z z4iqqZ3Oeaa9y1lc7jLF4yje0vyGkye6jwIex0RTtqJHoxwT6tI= =TMCH -----END PGP SIGNATURE----- --=_2534iIRQQ2aqQWEes438_4Z--