Date: Tue, 25 Apr 2023 12:30:16 +0200 From: Alexander Leidinger <Alexander@leidinger.net> To: Charlie Li <vishwin@freebsd.org> Cc: Ed Maste <emaste@freebsd.org>, Joerg Pulz <Joerg.Pulz@frm2.tum.de>, freebsd-arch <freebsd-arch@freebsd.org> Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 Message-ID: <20230425123016.Horde.YqdbqxIwT9cc_qCUq1zhsfj@webmail.leidinger.net> In-Reply-To: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> References: <CAPyFy2Afao5tnujFtwiF6avdkqAXRGDOTSq-JSCkHvvbfUvhaA@mail.gmail.com> <nycvar.OFS.7.77.840.2304201411080.78141@unqrf.nqzva.sez2.ghz.qr> <CAPyFy2DQsNLXmELTun6n590opjcAom-3MQE_jKda7AU4LdcGGg@mail.gmail.com> <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <vishwin@freebsd.org> (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--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230425123016.Horde.YqdbqxIwT9cc_qCUq1zhsfj>