From nobody Sun Apr 30 09:12:21 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 4Q8LFx2nc7z46Y0m for ; Sun, 30 Apr 2023 09:12:21 +0000 (UTC) (envelope-from rene@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8LFx2DSkz40Sv; Sun, 30 Apr 2023 09:12:21 +0000 (UTC) (envelope-from rene@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682845941; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zMR89dN8oPxJPRIuAgoJyiQ/qKx28Wc1VpW4y98h5dI=; b=HaygFjZ0y9cyxzWkDMgmVAAKdBrVU3wq3TKl5kDxrsZMH8awDdkSH7fOb54aXlr7XGKyiG +vZnzgY60FsAG+TqM4IDlthmEGioWYWwLmukf0zQkMeV/UoQROVJV/Brq8up/2jUddeNwU 5iegWftL3jvZcy/ZvkNwH5HIFiyiPbV1SV6sl8Ecb6OdQ4tCn3sq3/JGwcnyUOcOkIyo0X g9gR04Bfd/xev5YL4NRSZlA6CGI7vgMdJBPNuXNTvQySQGDPdDAD+GJ6AMGi0lMbUZmp4s Y3xDr75jveHeupPQpBsVUZYvl9a/xWlXJluAdzy0zbyk7i4jdb3uAVzyCALdng== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682845941; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=zMR89dN8oPxJPRIuAgoJyiQ/qKx28Wc1VpW4y98h5dI=; b=Dx18aC625kkhXBwd6vVohr3+a8pHsqZBttjjl65XvVRQcrmXqPAJdgmDeP1fkhTvBLNivR BGr3YEVxZ1olwcp4GieofAA3hVNCfuu0w4OHRoolfCFv+pFnWkrQa4tI40tlN2TOCRI+r3 BDR8B3nZVd6hzRNChFZLDwTzZNGR8tdHcPQmLxLrTLU+zjjxRthjjdYLw0XE4+a5Q/GxbF SvXUv+yUuvJraXSJZpUdtFZT92CVNBwuouZtZSIAHuwkAlo8sG5jv4l0AmTOZP7aQUdxIW 8cKue0csfQ3xsoNjL5J2X4y2wcardbUHxuIoXafMXmSr/XdgLxjJEl9DvLSgNg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682845941; a=rsa-sha256; cv=none; b=G3YfmJefacIbfSUphTFg/oCnuXCBkD4L3Xg54C4taO3JcuVIOUGODp/uKL329mX2wBDSbw UzvBk8b6PtqimFySwSKmvbH1YfqfmaZyKZxjMNxdaN9ZfSy53IrFoEev8QcjyxDqex0B1U djpxsFv0cqOQWtJEPtrh6oNigfWmfLOSHYB+cgdkaFlSFajnQ4+NYKbORdDIp9be5YOXF1 z0G8F2X+jNYH2Q3M3J5IYdp4Pyca82Doi5Wtto5rvR9FLbPaiKKY0SVz4GTAJkoB6SV2iY STFcKPIr9pPBRvnkN/lJrEOltGqpHhpeW8z2BOHy9HEPkziyGzvpFCRncqEqTQ== Received: by freefall.freebsd.org (Postfix, from userid 1185) id 3B3A26107; Sun, 30 Apr 2023 09:12:21 +0000 (UTC) Date: Sun, 30 Apr 2023 09:12:21 +0000 From: Rene Ladan To: Cy Schubert Cc: Warner Losh , freebsd-arch Subject: Re: Future of 32-bit platforms (including i386) Message-ID: References: <20230428071612.16ca02bd@cschubert.com> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20230428071612.16ca02bd@cschubert.com> X-ThisMailContainsUnwantedMimeParts: N On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schubert wrote: > On Thu, 27 Apr 2023 11:33:15 -0600 > Warner Losh wrote: > > > On Thu, Apr 27, 2023 at 11:20 AM John Baldwin wrote: > > > > > For 13.0, i386 was demoted from Tier 1 to Tier 2. In the announcement > > > of this for 13.0, the project committed to an update on i386's future > > > around the time of 14.0. The announcement at the time suggested that > > > i386 would be supported less in 14.x than in 13.x. > > > > > > > I like this. "In 14.0, i386 completes its journey to tier 2 status" maybe? > > > > > > > My proposal is that for 14.x we treat i386 like any other Tier 2 > > > platform. That is, release images and packages would only be provided > > > on a best-effort basis, and we would not guarantee providing them. I > > > think we should also stop shipping binary updates for the base system > > > (freebsd-update) for 14.x for i386. > > > > > > > So no freebsd-update service for i386 for 14.x, but have it for arm64 and > > amd64? > > That seems reasonable (assuming that arm64 works). > > > > > > > A larger question is what to do about 32-bit platforms moving forward. > > > My proposal for powerpc, i386, and armv[67] is that we say publicly > > > that we anticipate not supporting them in 15. That is, that we may > > > remove them outright from the tree, or we may leave them in the tree, > > > but we do not plan on building packages or release images. Another > > > option to consider for 32-bit platforms perhaps in 15 is to remove > > > kernel support and only retain the ability to build userland. The > > > goal of saying this now-ish (or about the time 14.0 is going to ship) > > > would be to give time for users and developers to respond in the > > > window between 14.0 and 15.0 so we can evaluate those responses as an > > > input into the final decision for 15. > > > > > > > I like this idea. It states intent strongly enough that people aren't > > surprised, > > but weakly enough that people with strong interests can show up. One lesson > > we've learned repeatedly in the past, though, is that we get a lot people > > showing up saying they'll do something, but then doing nothing. The > > threshold > > of doing something will be actually doing it and being an active member of > > the community or providing other material support rather than "Geeze, I'd > > hate to see sparc64 go, so I'll fix a port or two". I'm not sure how you'd > > set > > that expectation, but maybe something like "we'll evaluate the responses and > > the robustness, size and vitality of those communities as input into our > > decision" > > which would set the bar higher, and have something vaguely measureable to > > point at. > > > > Side note: We should stop providing packages and re-built images for armv6 > > in 14, even if we don't completely decommission support for it right away. > > That > > might prove to be a good model here as well and give us some good experience > > for how to do that with the other 32-bit platforms for 15. > > > > I generally favor this idea... It's also a natural evolution of what we've > > been saying > > about platforms, eg you need to provide 64-bit atomics and other operations, > > even if they are relatively inefficient because the base system is starting > > to use them. > > > > 32-bit going away is the long term trend, and the long term goal of the > > project. > > What remains in doubt is the timeline to accomplish this. Many 32-bit > > platforms > > still perform decently well, so we should expect to see some usage. But we > > need > > to weigh the size of that usage against the cost of providing it. We've > > seen an increasing > > cost to developers to provide this over the last few years. But as the > > usage drops > > the cost increases because unanticipated breakages become harder to fix as > > they > > are discovered further and further from the breaking point. > > Agreed. This brings us in line with virtually all major Linux > distributions, Oracle Solaris (whatever is left of it), the other major > commercial O/S out there (AIX), and the other major distributions of > BSD (except NetBSD). > > I think we need to nudge the ports team in this direction, sooner than > later, though in my experience, a good percentage of packages fail to > build on i386 anymore here anyway, including all browsers in ports/www. > >From my testing chromium still builds on i386, but that platform needs some more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support will be purged from the ports tree once 12 goes EOL in 2024, removing i386 and arm 6/7 should be a similar exercise. René > > > > Warner > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=0 From nobody Sun Apr 30 13:25:07 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 4Q8Rss1TVFz47pL8 for ; Sun, 30 Apr 2023 13:25:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q8Rsr40h9z3CwM for ; Sun, 30 Apr 2023 13:25:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-50bc394919cso600643a12.2 for ; Sun, 30 Apr 2023 06:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682861119; x=1685453119; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Cbb5BDEX5VVXcw+41w9RwQKkfo9LBXRtiCKJxv9nmdo=; b=0YMvoGx1mmQ6VNXvmRfyI/5cAt/AokZPWgEphBcBoF7Ht40/vs84OreEWqP3zLI2Ig pY8IEdgSzaXqp3FCETMLU3BqZzMgZmbwDkhE1NUizXIAaOUss61n9NBLw+sFLA2706nf eWcwf/9bQhfWU5nNh/ObzgrEigTlYymt4t+knD4Zd0edvQeGU7cisCLQupXOxCJWdcg2 f8zdjeDsVxK8bPqT+xOSsFVXPZxqa1rT8fuufbXc0HNsCvLr6iiAWiHG6QDYAITXsU29 DxqgfolIFiatRHBeJlw0YpjSJOS6RRgS/HkEk0Fybs27TlTAAL37FyirD24WEs+XPNkn 4hAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682861119; x=1685453119; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Cbb5BDEX5VVXcw+41w9RwQKkfo9LBXRtiCKJxv9nmdo=; b=K723almbzNCH1dqZBJm5v9zSf5kByCA2TFP+g9LpoOUrgrnajpl2wDT60WryPrerEM CTmJTCfhSjOTyB39ZeBRj9KyGbSf5HZzPE+kXjBWjadjnteZSqkXRA3e66O9PemIhJVn cjIgFJ2q3eYitIlKPTRKk40NOYw1PpoHtGwneC4G9/FsE5DYNxrHldbOxl7Fpks7hC/2 G+oKJWUjDGXZSMhHkQAokDR3u3yya6BHHq12E7UKICvMXOaMowbSrYO/pmEqAd7MQmX5 aIBKjRJsMz8X5oX6J6OwRfZ2xkKGz+2/Ze0PA44KU9we7Hqq1bA/QTCBVWhLcNtyRbS8 wM6w== X-Gm-Message-State: AC+VfDzn8lPKPctYkeSh8gigikfS75UpTAvbkEfZa+euSTfeT+YkL/Qi PmRN2T6cUzszi9Bv8ySlj2xqLDokxjKkPy7UdQeCJw== X-Google-Smtp-Source: ACHHUZ41hhxs5GDJGPN+bjYrG+BwtZosIk5sMyUrkYNlqpKC3U73y0aQuOPvviTRueL0MBpq7FFRIF6utbFwRVH14Yc= X-Received: by 2002:aa7:da5a:0:b0:506:c3c8:59cc with SMTP id w26-20020aa7da5a000000b00506c3c859ccmr3724144eds.27.1682861119014; Sun, 30 Apr 2023 06:25:19 -0700 (PDT) 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 References: <20230428071612.16ca02bd@cschubert.com> In-Reply-To: From: Warner Losh Date: Sun, 30 Apr 2023 07:25:07 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: Rene Ladan Cc: Cy Schubert , freebsd-arch Content-Type: multipart/alternative; boundary="000000000000349f2b05fa8da3c8" X-Rspamd-Queue-Id: 4Q8Rsr40h9z3CwM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000349f2b05fa8da3c8 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Apr 30, 2023, 3:12 AM Rene Ladan wrote: > On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schubert wrote: > > On Thu, 27 Apr 2023 11:33:15 -0600 > > Warner Losh wrote: > > > > > On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin wrote: > > > > > > > For 13.0, i386 was demoted from Tier 1 to Tier 2. In the > announcement > > > > of this for 13.0, the project committed to an update on i386's futu= re > > > > around the time of 14.0. The announcement at the time suggested th= at > > > > i386 would be supported less in 14.x than in 13.x. > > > > > > > > > > I like this. "In 14.0, i386 completes its journey to tier 2 status" > maybe? > > > > > > > > > > My proposal is that for 14.x we treat i386 like any other Tier 2 > > > > platform. That is, release images and packages would only be > provided > > > > on a best-effort basis, and we would not guarantee providing them. = I > > > > think we should also stop shipping binary updates for the base syst= em > > > > (freebsd-update) for 14.x for i386. > > > > > > > > > > So no freebsd-update service for i386 for 14.x, but have it for arm64 > and > > > amd64? > > > That seems reasonable (assuming that arm64 works). > > > > > > > > > > A larger question is what to do about 32-bit platforms moving > forward. > > > > My proposal for powerpc, i386, and armv[67] is that we say publicly > > > > that we anticipate not supporting them in 15. That is, that we may > > > > remove them outright from the tree, or we may leave them in the tre= e, > > > > but we do not plan on building packages or release images. Another > > > > option to consider for 32-bit platforms perhaps in 15 is to remove > > > > kernel support and only retain the ability to build userland. The > > > > goal of saying this now-ish (or about the time 14.0 is going to shi= p) > > > > would be to give time for users and developers to respond in the > > > > window between 14.0 and 15.0 so we can evaluate those responses as = an > > > > input into the final decision for 15. > > > > > > > > > > I like this idea. It states intent strongly enough that people aren't > > > surprised, > > > but weakly enough that people with strong interests can show up. One > lesson > > > we've learned repeatedly in the past, though, is that we get a lot > people > > > showing up saying they'll do something, but then doing nothing. The > > > threshold > > > of doing something will be actually doing it and being an active > member of > > > the community or providing other material support rather than "Geeze, > I'd > > > hate to see sparc64 go, so I'll fix a port or two". I'm not sure how > you'd > > > set > > > that expectation, but maybe something like "we'll evaluate the > responses and > > > the robustness, size and vitality of those communities as input into > our > > > decision" > > > which would set the bar higher, and have something vaguely measureabl= e > to > > > point at. > > > > > > Side note: We should stop providing packages and re-built images for > armv6 > > > in 14, even if we don't completely decommission support for it right > away. > > > That > > > might prove to be a good model here as well and give us some good > experience > > > for how to do that with the other 32-bit platforms for 15. > > > > > > I generally favor this idea... It's also a natural evolution of what > we've > > > been saying > > > about platforms, eg you need to provide 64-bit atomics and other > operations, > > > even if they are relatively inefficient because the base system is > starting > > > to use them. > > > > > > 32-bit going away is the long term trend, and the long term goal of t= he > > > project. > > > What remains in doubt is the timeline to accomplish this. Many 32-bit > > > platforms > > > still perform decently well, so we should expect to see some usage. > But we > > > need > > > to weigh the size of that usage against the cost of providing it. We'= ve > > > seen an increasing > > > cost to developers to provide this over the last few years. But as th= e > > > usage drops > > > the cost increases because unanticipated breakages become harder to > fix as > > > they > > > are discovered further and further from the breaking point. > > > > Agreed. This brings us in line with virtually all major Linux > > distributions, Oracle Solaris (whatever is left of it), the other major > > commercial O/S out there (AIX), and the other major distributions of > > BSD (except NetBSD). > > > > I think we need to nudge the ports team in this direction, sooner than > > later, though in my experience, a good percentage of packages fail to > > build on i386 anymore here anyway, including all browsers in ports/www. > > > From my testing chromium still builds on i386, but that platform needs so= me > more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support > will be purged from the ports tree once 12 goes EOL in 2024, removing i38= 6 > and arm 6/7 should be a similar exercise. > Of course if we decouple the user land from the kernel, we'll have to carefully coordinate that... and that might also be a consideration for how quickly we move in base: the ability to build 32-bit ports with poudriere. Warner Ren=C3=A9 > > > > > > Warner > > > > > > > > -- > > Cheers, > > Cy Schubert > > FreeBSD UNIX: Web: https://FreeBSD.org > > NTP: Web: https://nwtime.org > > > > e^(i*pi)+1=3D0 > --000000000000349f2b05fa8da3c8 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Sun, Apr 30, 2023, 3:12 AM Rene Ladan <rene@freebsd.org> wrote:
On Fri, Apr 28, 2023 at 07:16:12AM -0700, Cy Schu= bert wrote:
> On Thu, 27 Apr 2023 11:33:15 -0600
> Warner Losh <imp@bsdimp.com> wrote:
>
> > On Thu, Apr 27, 2023 at 11:20=E2=80=AFAM John Baldwin <jhb@freebs= d.org> wrote:
> >
> > > For 13.0, i386 was demoted from Tier 1 to Tier 2.=C2=A0 In t= he announcement
> > > of this for 13.0, the project committed to an update on i386= 's future
> > > around the time of 14.0.=C2=A0 The announcement at the time = suggested that
> > > i386 would be supported less in 14.x than in 13.x.
> > >=C2=A0
> >
> > I like this. "In 14.0, i386 completes its journey to tier 2 = status" maybe?
> >
> >
> > > My proposal is that for 14.x we treat i386 like any other Ti= er 2
> > > platform.=C2=A0 That is, release images and packages would o= nly be provided
> > > on a best-effort basis, and we would not guarantee providing= them.=C2=A0 I
> > > think we should also stop shipping binary updates for the ba= se system
> > > (freebsd-update) for 14.x for i386.
> > >=C2=A0
> >
> > So no freebsd-update service for i386 for 14.x, but have it for a= rm64 and
> > amd64?
> > That seems reasonable (assuming that arm64 works).
> >
> >
> > > A larger question is what to do about 32-bit platforms movin= g forward.
> > > My proposal for powerpc, i386, and armv[67] is that we say p= ublicly
> > > that we anticipate not supporting them in 15.=C2=A0 That is,= that we may
> > > remove them outright from the tree, or we may leave them in = the tree,
> > > but we do not plan on building packages or release images.= =C2=A0 Another
> > > option to consider for 32-bit platforms perhaps in 15 is to = remove
> > > kernel support and only retain the ability to build userland= .=C2=A0 The
> > > goal of saying this now-ish (or about the time 14.0 is going= to ship)
> > > would be to give time for users and developers to respond in= the
> > > window between 14.0 and 15.0 so we can evaluate those respon= ses as an
> > > input into the final decision for 15.
> > >=C2=A0
> >
> > I like this idea. It states intent strongly enough that people ar= en't
> > surprised,
> > but weakly enough that people with strong interests can show up. = One lesson
> > we've learned repeatedly in the past, though, is that we get = a lot people
> > showing up saying they'll do something, but then doing nothin= g. The
> > threshold
> > of doing something will be actually doing it and being an active = member of
> > the community or providing other material support rather than &qu= ot;Geeze, I'd
> > hate to see sparc64 go, so I'll fix a port or two". I= 9;m not sure how you'd
> > set
> > that expectation, but maybe something like "we'll evalua= te the responses and
> > the robustness, size and vitality of those communities as input i= nto our
> > decision"
> > which would set the bar higher, and have something vaguely measur= eable to
> > point at.
> >
> > Side note: We should stop providing packages and re-built images = for armv6
> > in 14, even if we don't completely decommission support for i= t right away.
> > That
> > might prove to be a good model here as well and give us some good= experience
> > for how to do that with the other 32-bit platforms for 15.
> >
> > I generally favor this idea... It's also a natural evolution = of what we've
> > been saying
> > about platforms, eg you need to provide 64-bit atomics and other = operations,
> > even if they are relatively inefficient because the base system i= s starting
> > to use them.
> >
> > 32-bit going away is the long term trend, and the long term goal = of the
> > project.
> > What remains in doubt is the timeline to accomplish this. Many 32= -bit
> > platforms
> > still perform decently well, so we should expect to see some usag= e. But we
> > need
> > to weigh the size of that usage against the cost of providing it.= We've
> > seen an increasing
> > cost to developers to provide this over the last few years. But a= s the
> > usage drops
> > the cost increases because unanticipated breakages become harder = to fix as
> > they
> > are discovered further and further from the breaking point.
>
> Agreed. This brings us in line with virtually all major Linux
> distributions, Oracle Solaris (whatever is left of it), the other majo= r
> commercial O/S out there (AIX), and the other major distributions of > BSD (except NetBSD).
>
> I think we need to nudge the ports team in this direction, sooner than=
> later, though in my experience, a good percentage of packages fail to<= br> > build on i386 anymore here anyway, including all browsers in ports/www= .
>
>From my testing chromium still builds on i386, but that platform needs some=
more handholding than amd64. So sparc64 and arm4/5 (and base GCC) support will be purged from the ports tree once 12 goes EOL in 2024, removing i386<= br> and arm 6/7 should be a similar exercise.

Of course if we decouple the user = land from the kernel, we'll have to carefully coordinate that... and th= at might also be a consideration for how quickly we move in base: the abili= ty to build 32-bit ports with poudriere.

<= div dir=3D"auto">Warner

=
Ren=C3=A9
> >
> > Warner
>
>
>
> --
> Cheers,
> Cy Schubert <Cy.Schubert@cschubert.com>
> FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeBSD.org
> NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2= =A0 =C2=A0 Web:=C2=A0 https://nwtime.org
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0e^(i*pi)+1=3D0
--000000000000349f2b05fa8da3c8-- From nobody Mon May 1 16:34:41 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 4Q981v2HSBz48kVZ for ; Mon, 1 May 2023 16:34:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q981v1pzXz40wW; Mon, 1 May 2023 16:34:43 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682958883; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G9z/R9m9mvL6ywT+3JRFOqByTzGKWDs7M+wRQRxKMVk=; b=lIiudl8FRLx2/siPL6lX2tgON6Q1jlGpQ9i499W0Zo5Lbu6M+yoXSFP28giV9I4rx0PHSb n8DgEQMw/b34ejkOGeTeyZhqnOFKVM3mou1TEStYDMlhHgtBkjFipYEvtfbb02mzEhAGB6 tH+r4lT1U96ED5/IFyNYS6gZJ4jhEyViYBmi9HsV8LPsWaEB65/PFknLLQ66KPRB4CwkKE v3J99UibOivfzjel5Yy/ZSLmNIHTrN+8CEcCPnn+pYuCbVmm5SMyJ49RYHN5UtJiIGhMWO hgtGyukppqK3xwc+bIV50nSKbtG1tcCiREWUvKLBaQRBvUzmAs0UqbB4FN/Jkw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682958883; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=G9z/R9m9mvL6ywT+3JRFOqByTzGKWDs7M+wRQRxKMVk=; b=SxaUN3aL4liZVAQBeQM9yngTHtNr6DsSelDqDdQlTFPiEA4XAzxhrZ/GtZ5EINixF8VHc1 p8Fp0dK4Qgde72DbctIupRns3O1isg8TGFwhS5qO9S1D0tXrWzkNe0yHWx3YAT5puO+H8C 4m7APZLsnmqD9MWeyP032WT07ipW7zO+GKp68/tXaf9pwSNvgLxg5KXk/2AOFmBRBsGt6j Xocjp6W7WNO682ntI//vBHaxs89eJ8HhuPR3HHRxkIeZH4Era/v/3ha+llNZGLUrLM0ptk ihKArWAmWzP9kb6oBbU+4Z7+F7EmAotafXLbV2c7FgkQMVfDJcKHPOdUghsKOg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682958883; a=rsa-sha256; cv=none; b=yVTKqHuU9Ofg0JsVS0/LcjIRkCnVxKNAq6CuEW3zczV+1SAc4zxqyAJFfDn8z7qczMlY9n /dCp3aTh0QZZMP6CTkx7G14Mvpn0r5m98aKcJc1NX8mHvuHnn8GNsL8aGNOI+4FM6JpkCx 9AaCB8X34RC5clws0iTvjD4JFCmuRgTi3gczhp7jBKtZUie/oFJXmr/iGn24QQuOp9X9tI cadBwHCNNm9J2kkrBvdscb0eczwVAmSaDxlpJSJWS+DeQQFn6YfhA7rShHJLkj2ElYgypr XHqdpcYKRWPXvt3/E9Ah4jk6YKA7E5UcCa+y3eEQAGWY56+tpBwbL8N/9zogTQ== Received: from [IPV6:2601:648:8680:16b0:6863:4e51:eaeb:9500] (unknown [IPv6:2601:648:8680:16b0:6863:4e51:eaeb:9500]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q981t61jNznTW; Mon, 1 May 2023 16:34:42 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <5dcf4aae-258d-c0a0-91f6-ffa77177e716@FreeBSD.org> Date: Mon, 1 May 2023 09:34:41 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: Future of 32-bit platforms (including i386) Content-Language: en-US To: "Simon J. Gerraty" , 'freebsd-arch' References: <82207.1682727452@kaos.jnpr.net> From: John Baldwin In-Reply-To: <82207.1682727452@kaos.jnpr.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-ThisMailContainsUnwantedMimeParts: N On 4/28/23 5:17 PM, Simon J. Gerraty wrote: > John Baldwin wrote: >> A larger question is what to do about 32-bit platforms moving forward. > > FWIW while we do not use i386 kernels anymore > compat32 support is very important. > > Some of our daemons are very pointer heavy and up to a certain scale > point, a 32bit app is more memory efficient, of course the 64bit version > can scale much bigger but many customers do not need that. Are you able to build your daemons with cc -32 with an amd64 world, or do you require an i386 world to build against? -- John Baldwin From nobody Mon May 1 18:02:53 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 4Q99zt1d2Mz48q5C for ; Mon, 1 May 2023 18:03:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ej1-x62e.google.com (mail-ej1-x62e.google.com [IPv6:2a00:1450:4864:20::62e]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q99zt1D3Mz47Vp for ; Mon, 1 May 2023 18:03:06 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ej1-x62e.google.com with SMTP id a640c23a62f3a-94f7a7a3351so559347366b.2 for ; Mon, 01 May 2023 11:03:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1682964185; x=1685556185; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=opam/zW8HJWbEpeVFslzCvcZini1lxTktNqTMOL10WU=; b=vnkaGzhtDJ+5hnqyt/osGlpk2Dbo/axG/5UeD6pDqXB0S96WxPPOISJQE31Z++fWAb nbEAhYY3TnsWjVkBSCmdn6GXBOYXUKHa0KC2vsKqM0Ldr7XD6oAqqETpO03I7qU2woFd Wu9Ie9QzlbC1SoMgPQ+qRKePa9rWyHtHZ+eAtdNlQNva2BC+YHu8AYXoFl4uc19bRVzQ hhvRVufKvmb0hC3lYNWUdf0xJJrdliewbNxpeMFZwFPiVRXNqeUwwOKDoxig1ZLsljyU i0SeJhZWF1aiKT7rMwtF+PmgN8tSOe0dpbL7b1Tepobnom7PgOiBNV0yYvXIh/v+q0PW e2Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682964185; x=1685556185; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=opam/zW8HJWbEpeVFslzCvcZini1lxTktNqTMOL10WU=; b=XgcwujATCqSxb96tQOFC451lMfmSAqtLqn9YowsZeDqd1rfULhnfy+yKL/zhwXeMkD 3abNkSURNJqsml0EUI97FLmfhW2N2gBs1dHksQnIR1EWm2m5G0KRz1aKbh9eiQs5qlB9 hywEqjEHvVAB/+Qwj6ELfQO3BdRX8upbRP+9rGalAHLk6VUgIkDbcTlwDx3iS7zT5kK9 GML3Rz3QAfsgFKyRR+VHwtA0k55i8Q0nuMZr2ZSPdL1XxXpl2FJIMvihAQt1aN8V8Vf7 YI8VImD+/v11AwIU0TmJEAsR4qRDzstukvBcQ+p/0FPpFQdXOohi7pLnFUSzoZPRpAUW q0yw== X-Gm-Message-State: AC+VfDzlUe6Z3L1wfl5ZZwIw1CmXDrXfAQFLshXmj46U9vxJ8mE0SNX7 ECoMVj/CjwtpLvhPeGWZyojCnvSsQoEc+Sq9swUAFRJshDJx0Nz9 X-Google-Smtp-Source: ACHHUZ7OVOFwg4cBkQA50EbPfmA/WAnXkW+mLwG8n33/YDp4g1f7RE/4rNrESP3LglxQrTniuuPfQghJPT1+F1yBgjc= X-Received: by 2002:a17:907:7207:b0:94f:2efa:a3eb with SMTP id dr7-20020a170907720700b0094f2efaa3ebmr13245467ejc.33.1682964184716; Mon, 01 May 2023 11:03:04 -0700 (PDT) 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 References: <82207.1682727452@kaos.jnpr.net> <5dcf4aae-258d-c0a0-91f6-ffa77177e716@FreeBSD.org> In-Reply-To: <5dcf4aae-258d-c0a0-91f6-ffa77177e716@FreeBSD.org> From: Warner Losh Date: Mon, 1 May 2023 12:02:53 -0600 Message-ID: Subject: Re: Future of 32-bit platforms (including i386) To: John Baldwin Cc: "Simon J. Gerraty" , freebsd-arch Content-Type: multipart/alternative; boundary="000000000000666ff805faa5a203" X-Rspamd-Queue-Id: 4Q99zt1D3Mz47Vp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000666ff805faa5a203 Content-Type: text/plain; charset="UTF-8" On Mon, May 1, 2023, 10:34 AM John Baldwin wrote: > On 4/28/23 5:17 PM, Simon J. Gerraty wrote: > > John Baldwin wrote: > >> A larger question is what to do about 32-bit platforms moving forward. > > > > FWIW while we do not use i386 kernels anymore > > compat32 support is very important. > > > > Some of our daemons are very pointer heavy and up to a certain scale > > point, a 32bit app is more memory efficient, of course the 64bit version > > can scale much bigger but many customers do not need that. > > Are you able to build your daemons with cc -32 with an amd64 world, or > do you require an i386 world to build against? > If the latter, do you use a chroot to build any ports Warner -- > John Baldwin > > > --000000000000666ff805faa5a203 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, May 1, 2023, 10:34 AM John Baldwin <jhb@freebsd.org> wrote:
On 4/28/23 5:17 PM, Simon J. Gerraty wrote:
> John Baldwin <jhb@freebsd.org> wrote:
>> A larger question is what to do about 32-bit platforms moving forw= ard.
>
> FWIW while we do not use i386 kernels anymore
> compat32 support is very important.
>
> Some of our daemons are very pointer heavy and up to a certain scale > point, a 32bit app is more memory efficient, of course the 64bit versi= on
> can scale much bigger but many customers do not need that.

Are you able to build your daemons with cc -32 with an amd64 world, or
do you require an i386 world to build against?
=

If the latter, do you use a c= hroot to build any ports

Warner

--
John Baldwin


--000000000000666ff805faa5a203-- From nobody Mon May 1 18:14:49 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 4Q9BFX15KGz48qS3; Mon, 1 May 2023 18:14:56 +0000 (UTC) (envelope-from gjb@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9BFX0SJcz4BpD; Mon, 1 May 2023 18:14:56 +0000 (UTC) (envelope-from gjb@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682964896; 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; bh=982sUHCVyS2oRa34lrZYsnJAj5HelSWghZYUY1qthSo=; b=e2uyA5Q6AD9bbISlvsMI0vyfsPzicaOC7XD5E+MKNMw+fJbaWceMZvlzdSje7Fte3zvK0P FrlCBGI5aTy34N3Dz+5wTSFfvK4ynDogYuDHU07+4H7Pe9GLunqGYvuZ8wa+qJFB5y4jZQ AGgXtDITDYY2ipt7MbmFd5D8qPuzQPrlHrq722VREPrjQtFcXK8wHfZW5+AFgs1cVtj8CU /zEVQmHdbUwT7KG2KE8HJtXHJ6rFxo+joUyYMp3wE6WUWz0Q+FZejk4///8wSc9GK+gHov MNMhEr8Ft5tPFvz+42X4K0aJtvoKtFtcM2+CEf+K7Vhgc9D76xyG0wdHlf/Ujw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1682964896; 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; bh=982sUHCVyS2oRa34lrZYsnJAj5HelSWghZYUY1qthSo=; b=ooBppsiqA/6CY/P+1fmTIFw3W2g+8gW2ykyuUczDT6bUBaTrLiwPe1BtbX9XMx/RefFJSD YIYGtL9gJhFcXL13E8xQzFj0ExuMg/PVctVfqKyxLcR4rQ9H5O/2y3MfrAvrQGO9ix9YNo PiLGJXHVlXPmEsbwXpWA3bksTjNwPL4gedhtJ/Ml8WQlUHKoYhXmPbwc0yA5R0JDRT6glF mjKp5kjfVAzK5hc5fJ9fBKwTTTTY/oV6h3/UC79lKfAU7vl3dml0wxo/Hk/rSGFl6Eqr9V JDaZX6gKs+ZlewGC2KUYJ7sfJ/DM6WW75HHBTeNBhQdJ0Emz9KVYqQ9DrnazAg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1682964896; a=rsa-sha256; cv=none; b=Nt/9fSS1IBJon5alsFoswCLb7BHObHOmSLrR3nV+C6xhEq6d2Ss6idHhxCS9YUAuNLzgob I8yyLUI2FYNsTLc7JD3u8OlhqYwLC+Xg34gzjSLVwXqKWAfD094VGfo6/eyGvoAPyd5zlp qyZNnzE6ZzTiEBk+GB5JPLibv5AI9tUA/MBntGBrlg9mL5nLPnfLruni/ClATJVupto0bD LLiHWMCsQzJVm5rEHSpfA8axTMBJVc3E8G1XQ5/OeWb4XR6VwbkUgo++YHinJWTHZEskMG Y7N0OpSrAtriGeIwd0VfjHeKglNE5kiqOzDVztsGAaUU3ntuEj3EvGlG+5+ppg== Received: from FreeBSD.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by freefall.freebsd.org (Postfix) with ESMTPS id 87671B0E9; Mon, 1 May 2023 18:14:55 +0000 (UTC) (envelope-from gjb@freebsd.org) Date: Mon, 1 May 2023 18:14:49 +0000 From: Glen Barber To: freebsd-arch@freebsd.org, freebsd-hackers@freebsd.org Cc: freebsd-current@freebsd.org, FreeBSD Release Engineering Team , FreeBSD Security Team Subject: Delay in 14.0-RELEASE cycle and blocking items Message-ID: <20230501181449.GJ1219@FreeBSD.org> 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 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cyV/sMl4KAhiehtf" Content-Disposition: inline X-ThisMailContainsUnwantedMimeParts: N --cyV/sMl4KAhiehtf Content-Type: text/plain; charset=us-ascii Content-Disposition: inline According to the 14.0-RELEASE schedule, the code slush in main and the freeze to the KBI for 14.0 was scheduled for April 25, 2023. As some of you may have noticed, that did not happen. First, and most importantly for 14.0, is the status of the OpenSSL update to version 3. This in itself is reason to delay the schedule until some tangible progress has been made. Yes, some have expressed interest in helping in this area, however at this moment, this is the key blocker. Second is the status of the branch and how it pertains to the recent upstream merge from OpenZFS. Although block_cloning is disabled by default, there have been other regressions discovered (and fixed), but as a whole, I do not feel that we have a solid understanding of the regressions about which we do not know. There is no feasible way we are going to make the branch point of stable/14 in time, with that scheduled for May 12, 2023 with the above points. That said, this is not an all-inclusive list, but the more major items on our radar at the moment. A more up-to-date schedule for the 14.0 release will be published in the near future, though nothing is yet set in stone. Thank you for your patience, and for any help in getting us through these outstanding items. Glen On behalf of: re@ --cyV/sMl4KAhiehtf Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEjRJAPC5sqwhs9k2jAxRYpUeP4pMFAmRQAZkACgkQAxRYpUeP 4pPQJg/8CO1Z12iekJPausELsStIi0rsCxZPtx9wOXAOKWIJmc85ss35UFluPbWy 8iKAciUuHqCTg7GebTPpkbTx/MptAvbO+xFbKfiGPUrRLuLF4DftKvMyaaDWqo7K nUZ5ob3ldLaPkiYGjJ3vayf1HvXTa9bHf8I0eie/fY8fm20Yro00dYGDcr1UoxoQ QPUDJ7hulN11nw6mt/ywHM5gYTe3hT4BphJ+KLu+5tayEvmv7sgFd7F/oXW4BnPo BZsi0jZf49udUxdFpssyzaQsV5fyZYgjeelG/znQ6bQPO9PwE3NJEzTUz19F0MWY lxuJeuyB3iz5ZBEvNLbHXxKjBCTjANN8l2lUU4iQshm1nKIR3SbaTw6P/3L79UwF aP+1OAMpwKT+1xnZRWnrMWmpDEcrWjvXy4aBmpTXobxHT5zpBU1lecKGmpFWpOMp KJEDEEndQlgTZh2KfWE80xIWnnvG7dEkxdIgyHXeYjSrkUqCA8wsZqmV7LOdCFxv rUDjeuhcDQNsgEXMM2e+OTt+TAb7xIagX7cYqTN9ATZjzHcbP65jfBhi7dYF7lhZ Thrj1+u5xzNqc2bbEuZbZBWK0+hp+Z0DoKy/ka3XNguP868+SmsG07KErnLr+KYU j20ZRz5S2iKrmdXtkc2Rn0FY/CUOJievJtIun6dY2tfkUBJNcm0= =aAce -----END PGP SIGNATURE----- --cyV/sMl4KAhiehtf-- From nobody Mon May 1 21:09:18 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 4Q9G7j1YVWz491q9 for ; Mon, 1 May 2023 21:10:09 +0000 (UTC) (envelope-from sjg@juniper.net) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.pphosted.com", Issuer "Thawte RSA CA 2018" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9G7j0QCwz3Ndq; Mon, 1 May 2023 21:10:08 +0000 (UTC) (envelope-from sjg@juniper.net) Authentication-Results: mx1.freebsd.org; none Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 341DF3t8030824; Mon, 1 May 2023 14:10:06 -0700 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=to : cc : subject : in-reply-to : references : from : mime-version : content-type : content-id : date : message-id; s=PPS1017; bh=KBlqH1KWIj9XFDD7IoZGq8NPaUTc9zK5OR/FL0R1yl8=; b=qswq+OftjzbFfm48b4EMDy51HgmljpuYmI1nKbUB3QKyMGF3Wj8K97DjEnNi88UcLpmx zOVGvh8tsNAEo90zd9cpWj+g8cMRFk04VqXMw26tXJ/DUaNxrtX6q1qiX3jV4S+Gu/4s y4O0yPHvTJ2MAbNsEFFuFApitlCpmTp/4PgTP4IwztUR69BBiBMclVM6EQLSh+hZTAxD mg55L7pYTzjTxvO3+IxSDpOPayy9Pey+8XJGK5O7rw3KCjC97dzAtF//KLUuPa81xE9a ksJzH9ECj4CK/WlfYf+9k8yX5qRg2GSWUWUfLB+DzOIv+wDycpN42tO9HGUyP+yoYyAL Ug== Received: from mw2pr02cu001.outbound.protection.outlook.com (mail-westus2azlp17012026.outbound.protection.outlook.com [40.93.10.26]) by mx0a-00273201.pphosted.com (PPS) with ESMTPS id 3q916xubbn-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 01 May 2023 14:10:06 -0700 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kFSWgTssXFi4BmD6kS1Wn2AXgpMfjPIaEZeghX4gCfJO/uaPld6xzYR67k+Rb4cLe2YFyhm5EAB87JEN6boDSnCoHt7++5sYeE1kBADYFSiL1uAf/OtVS/1MUWxxB/DO7aC8WigUpFeabTtpDySAMuh29udfR49nNh12n1GNufWpkLA5CsW/ZyNNR9p3SAUtxheAcmK7mMg5j1kX8Xx29v3XBpVLUGbDDKTEFUcjB/B8Chd5pVEDDEHeF9p5cAs7HyhqOceQyIw6D/rLrzgfIcZrCvEQ9Rf77nETfaxO3HFngN+sUhhiG64w9Drg4Xg8/D38IXeEnIrOdeeFepkmhg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=KBlqH1KWIj9XFDD7IoZGq8NPaUTc9zK5OR/FL0R1yl8=; b=WLT9zlAW9hkUMeJvNgv4pHofNEq7ALO7Q7OPs1cp3/QD+Jyy0scbQj6azOZVaxT68GaTfPEYuOOYtYOov4b0chSBeoQMrHNYNhdXboKOfUaRMpv7cbZwAsRvsUYOu1oKsiFwV0WB3Ho8aova6rlFeCI1tfWqVCB+Z6fc6yCJ/qScdeD9IxJkrlD2u9GRmGjpy7qVm5eBK1S7b/EL27yazycXzZh+2zdhmo43nQJ6XEIZhyou95czdzvOOS78oAADmOd4BG5Oxn1keVvi5jx/z6njm+uhJ5IcRIaGQFvGp6aweDdQgjALp7SirafjLxh5Y4tBrQ0G7p1wMVEHE7Iclw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=softfail (sender ip is 66.129.239.15) smtp.rcpttodomain=freebsd.org smtp.mailfrom=juniper.net; dmarc=fail (p=reject sp=reject pct=100) action=oreject header.from=juniper.net; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=KBlqH1KWIj9XFDD7IoZGq8NPaUTc9zK5OR/FL0R1yl8=; b=U+TA2SBVpMdHBN1oeqebr3Dl6Ymdn0vZ8Jhp/JFepXm7JZ7p20MNKdHzjrDkLSkUgsIB7tTezGKSJz0BB0s3KB2TRkI3mQpMEesqFK0ofbcgqtKYlnJ3fADnf0ObPUTmaTYBfWq47N7YMOInXcvlyPj4Mlo44MtmEJwDe9kfZJY= Received: from DS7PR05CA0063.namprd05.prod.outlook.com (2603:10b6:8:57::19) by BYAPR05MB6454.namprd05.prod.outlook.com (2603:10b6:a03:eb::31) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6340.30; Mon, 1 May 2023 21:10:01 +0000 Received: from DM6NAM12FT077.eop-nam12.prod.protection.outlook.com (2603:10b6:8:57:cafe::e4) by DS7PR05CA0063.outlook.office365.com (2603:10b6:8:57::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.19 via Frontend Transport; Mon, 1 May 2023 21:10:01 +0000 X-MS-Exchange-Authentication-Results: spf=softfail (sender IP is 66.129.239.15) smtp.mailfrom=juniper.net; dkim=none (message not signed) header.d=none;dmarc=fail action=oreject header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from p-exchfe-eqx-02.jnpr.net (66.129.239.15) by DM6NAM12FT077.mail.protection.outlook.com (10.13.178.125) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.19 via Frontend Transport; Mon, 1 May 2023 21:10:01 +0000 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchfe-eqx-02.jnpr.net (10.104.9.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Mon, 1 May 2023 16:09:59 -0500 Received: from p-exchbe-eqx-01.jnpr.net (10.104.9.14) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7; Mon, 1 May 2023 16:09:59 -0500 Received: from p-mailhub01.juniper.net (10.104.20.6) by p-exchbe-eqx-01.jnpr.net (10.104.9.14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.2.1118.7 via Frontend Transport; Mon, 1 May 2023 16:09:59 -0500 Received: from kaos.jnpr.net (kaos.jnpr.net [172.23.255.201]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id 341L9wCe011663; Mon, 1 May 2023 14:09:59 -0700 (envelope-from sjg@juniper.net) Received: by kaos.jnpr.net (Postfix, from userid 1377) id 33DBD88371; Mon, 1 May 2023 14:09:18 -0700 (PDT) Received: from kaos.jnpr.net (localhost [127.0.0.1]) by kaos.jnpr.net (Postfix) with ESMTP id 3293C88634; Mon, 1 May 2023 14:09:18 -0700 (PDT) To: Warner Losh CC: John Baldwin , freebsd-arch , Subject: Re: Future of 32-bit platforms (including i386) In-Reply-To: References: <82207.1682727452@kaos.jnpr.net> <5dcf4aae-258d-c0a0-91f6-ffa77177e716@FreeBSD.org> Comments: In-reply-to: Warner Losh message dated "Mon, 01 May 2023 12:02:53 -0600." From: "Simon J. Gerraty" X-Mailer: MH-E 8.6+git; nmh 1.7.1; GNU Emacs 28.2 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 Content-Type: text/plain; charset="us-ascii" Content-ID: <57756.1682975358.1@kaos.jnpr.net> Date: Mon, 1 May 2023 14:09:18 -0700 Message-ID: <61859.1682975358@kaos.jnpr.net> X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: DM6NAM12FT077:EE_|BYAPR05MB6454:EE_ X-MS-Office365-Filtering-Correlation-Id: 67a293a9-db85-4b32-4d8e-08db4a886d7a X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: bd2hKvIF/Ic/G28GMI2OoNPlvZieRxL1pal0bFEhNlB54pfN9Vgj/yCM4b1s9GAAKDRpuflt+nezVgR6SlG9sJ4+fZSeDndw0mtBbToqGaZ7NgovQjgCKx3hd+3j31iJL0PLf1xfurClHx8yifb+fRDNOGjY7dPS+jXiVmDwGSoKDHvAhmk7iWbvOSa7d712uw3puiQ6b22+jOc7WJeTLcr8Ra1lWYhg0fv5wq2pHyIo5pKPvCuFiTWX0gCZ8XY/qv+jq0EiPSPgmf226kL0gpuGbIcwf/HC0T+OfBk3i4C62XPOlUK15UcYJALS1prOUipGg0tjyKZjrFFl1pTCv50HJf+Ae4bcNcOd2QXY9Axuuj42t3djbAZ0eK0CRttq3IPdMYHYOp34na7ddHDVkj0POQ27s8ba4/OAe4sXwhWH2Dh4lQeyC122WiKruIZAZdqg2X3t/UPzOZV0nEgHeSkHM4wkF0FGcKNCBR6rh4T/WvVgFw3vMY9EYL0toMOjWcfVg4dZ9PbBk837T4JQIH4qQqwAqOo2JBg7P7fVqDUS5K3A/PO03+tv8SDUXHJmGPYoS1hPQSwpJoIPONlmHYlunx+IclcsMjfTg8VLa1j+co6dgFBEnbitvTYhv34G8GxRJXaeNFUkWu9SK70ou8fXXMCYp3EJGBU7T/tyBl/E9JyURoLoYDeV28SlKifdNnh+C6NgkH8GrA/6rjzF1zNNEc/qrKkNSZFQooQFs+U= X-Forefront-Antispam-Report: CIP:66.129.239.15;CTRY:US;LANG:en;SCL:1;SRV:;IPV:CAL;SFV:NSPM;H:p-exchfe-eqx-02.jnpr.net;PTR:InfoDomainNonexistent;CAT:NONE;SFS:(13230028)(4636009)(396003)(136003)(376002)(39860400002)(346002)(451199021)(46966006)(40470700004)(36840700001)(336012)(86362001)(7696005)(5660300002)(186003)(40480700001)(54906003)(4744005)(316002)(82740400003)(6266002)(2906002)(47076005)(70206006)(356005)(81166007)(70586007)(4326008)(6916009)(41300700001)(36860700001)(7126003)(107886003)(26005)(9686003)(8936002)(8676002)(82310400005)(40460700003)(478600001)(55016003)(36900700001);DIR:OUT;SFP:1102; X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 May 2023 21:10:01.4859 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 67a293a9-db85-4b32-4d8e-08db4a886d7a X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4;Ip=[66.129.239.15];Helo=[p-exchfe-eqx-02.jnpr.net] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM12FT077.eop-nam12.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB6454 X-Proofpoint-ORIG-GUID: eVSZZ4FqoccTyKbJ-r0G3tQD38e2xC4W X-Proofpoint-GUID: eVSZZ4FqoccTyKbJ-r0G3tQD38e2xC4W X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-05-01_13,2023-04-27_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 phishscore=0 lowpriorityscore=0 mlxlogscore=581 adultscore=0 bulkscore=0 suspectscore=0 priorityscore=1501 malwarescore=0 impostorscore=0 clxscore=1015 mlxscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2305010170 X-Rspamd-Queue-Id: 4Q9G7j0QCwz3Ndq X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:26211, ipnet:208.84.65.0/24, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N Warner Losh wrote: > > Some of our daemons are very pointer heavy and up to a certain scale > > point, a 32bit app is more memory efficient, of course the 64bit version > > can scale much bigger but many customers do not need that. > > Are you able to build your daemons with cc -32 with an amd64 world, or > do you require an i386 world to build against? We don't buildworld, and we do not build 32bit apps as such in our freebsd tree. We build 32bit libs (and loader) and publish these for use by Junos. For main we are using -target i386-unknown-freebsd14.0, but clang is not built as part of freebsd. I think all we require is compat32 support in the kernel, and the ability to build libs for i386. > If the latter, do you use a chroot to build any ports We do not build any ports. Thanks --sjg From nobody Tue May 2 01:55:09 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 4Q9NSh0X40z48HVL for ; Tue, 2 May 2023 01:55:16 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9NSf0RsYz44mv; Tue, 2 May 2023 01:55:14 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20221208 header.b=P2FhMSn3; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::435 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com; dmarc=pass (policy=none) header.from=gmail.com Received: by mail-pf1-x435.google.com with SMTP id d2e1a72fcca58-63b4960b015so2268272b3a.3; Mon, 01 May 2023 18:55:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1682992511; x=1685584511; h=to:cc:date:message-id:subject:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=qVLE8njUoQPjNGR4y9gbx5nNbUTPd836XGnEe2bPq3Q=; b=P2FhMSn3+2Auw1ErzuZW56HogANIVy6mwh0utMQxVF5y/qpyhaMVzMZ/b6kAp5xkfO qoJhlYZptYgbWlv4uJHbG9iDXwQJRyYcaXDzoWrJSmLFbf5kia0Jt7dGbzUdyc+n+mEW hjM94m+DM1fAEGu3N44PNrwMGIiWpBrDHnNb+OEmZOh4Z/ZRxpAhDo7Hd/fk0IMuiafb CUCpY5wL/jyDWXZDHbkMLcdAhzAnPpQ8oEGmjb/w9Z2wOh1kji6jOuu8FuoQIEzWQMvA o3zNvSXdygO3R69CBlLFBsFvKaWuuFfhzrfe5TQM1QqspinUHj2pArIKyAuC3pzp/2T5 E04Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1682992511; x=1685584511; h=to:cc:date:message-id:subject:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=qVLE8njUoQPjNGR4y9gbx5nNbUTPd836XGnEe2bPq3Q=; b=XoMCi/fAiSj/Nlhtj3Dzgb+PsgRG4z/e/+AfhcShpYZvUI2/a+smNSAgtAZ814EHh3 P1BAvS0aWSq04qrJPpmntJrsigL/jOwTxb0Em7/wwvmlNDU2HBkUXHF6kxrTvXWL06S0 bJRfhPqHPEXQkmicNMscHifWVor8jHPlZZwnCpn5fbJ8HpRXCTuYRw0iER+JzfH4CdGd m8qffWNKj+YnVGae11zy5/hVt7Ljo+EpLhyTxFtQozqEkEQaBLoCxp0SAsmUWpmfHUfE JJZ/+ceJmCvukEUZzZdITuF2HrQcfTC+YCTriwvsVY4fWP28603q9ayYvJ9498P7mCH3 cPtA== X-Gm-Message-State: AC+VfDxDUhmwgr1MzHOYYcLEOgxSb1v+WTgH/hEPri3McBEXwDvLWr6W Z6bSnGrbspppefnqkDCSEpXUJ4kitrP2lQ== X-Google-Smtp-Source: ACHHUZ6p8bSeYK6X/4+ir7t8txrmQkhs9Tql/QyHuLIkR5TySK1+Uc5oOCyaWhwaPcO2P+enwcKzow== X-Received: by 2002:a05:6a21:3294:b0:f2:6fc6:9ca3 with SMTP id yt20-20020a056a21329400b000f26fc69ca3mr21513263pzb.43.1682992510890; Mon, 01 May 2023 18:55:10 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id c9-20020a170902b68900b001ab016ea3f9sm1470402pls.21.2023.05.01.18.55.09 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Mon, 01 May 2023 18:55:10 -0700 (PDT) From: Enji Cooper Content-Type: multipart/signed; boundary="Apple-Mail=_9881111A-489D-436B-924D-4A8CB3A4030F"; 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 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Message-Id: Date: Mon, 1 May 2023 18:55:09 -0700 Cc: bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org To: FreeBSD-arch list X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Spamd-Result: default: False [-5.59 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.99)[-0.987]; MV_CASE(0.50)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20221208]; MIME_GOOD(-0.20)[multipart/signed,multipart/alternative,text/plain]; ARC_NA(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; RCVD_VIA_SMTP_AUTH(0.00)[]; FROM_HAS_DN(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; HAS_ATTACHMENT(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCPT_COUNT_FIVE(0.00)[6]; DKIM_TRACE(0.00)[gmail.com:+]; RCVD_COUNT_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::435:from]; FROM_EQ_ENVFROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org] X-Rspamd-Queue-Id: 4Q9NSf0RsYz44mv X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9881111A-489D-436B-924D-4A8CB3A4030F Content-Type: multipart/alternative; boundary="Apple-Mail=_59A391A5-ABC1-4FE9-A7EE-086D06A8BF3D" --Apple-Mail=_59A391A5-ABC1-4FE9-A7EE-086D06A8BF3D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello, One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL 3.0 into the base system. This is a must because, in short, = OpenSSL 1.1 is no longer supported as of 09/26/2023 [1]. I am proposing OpenSSL be made private along with all dependent = libraries, for the following reasons: 1. More than a handful of core ports, e.g., = security/py-cryptography [2] [3], still do not support OpenSSL 3.0. i. If other dependent ports (like lang/python38, etc) = move to OpenSSL 3, the distributed modules would break on load due to = clashing symbols if the right mix of modules were dlopen=E2=80=99ed in a = specific order (importing ssl, then importing hazmat=E2=80=99s crypto = would fail). ii. Such ports should be deprecated/marked broken as = I=E2=80=99ve recommended on the 3.0 exp-run PR [4]. 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes = linking in both libraries at runtime impossible without resorting to a = number of linker tricks hiding the namespaces using symbol prefixing of = public symbols, etc. The libraries which would need to be made private are as = follows: - kerberos - libarchive - libbsnmp - libfetch [5] - libgeli - libldns - libmp - libradius - libunbound I realize I=E2=80=99m jumping to a prescribed solution without = additional discussion, but I=E2=80=99ve been doing offline analysis = related to uplifting code from OpenSSL 1.x to 3.x over the last several = months and this is the general prescribed solution I=E2=80=99ve come to = which is needed for $work. My perspective might have some blind spots = and some of the discussion done over IRC and might need to be rehashed = here for historical reference/to widen the discussion for alternate = solutions that don=E2=80=99t have the degree of tunnel vision which the = solution I=E2=80=99m employing at $work requires. I=E2=80=99ve tried to include some of the previously involved = parties so they can chime in. Thank you, -Enji 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ = 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 = . 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions require rustc to build, which apparently doesn=E2=80=99t work = on QEMU builders due to missing emulation support: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 = . 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 = 5. If I remember correctly, some folks suggested that making libfetch = private wasn=E2=80=99t required since the only port that required it was = ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. --Apple-Mail=_59A391A5-ABC1-4FE9-A7EE-086D06A8BF3D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
Hello,
One of the must-haves for = 14.0-RELEASE is the introduction of OpenSSL 3.0 into the base system. = This is a must because, in short, OpenSSL 1.1 is no longer supported as = of 09/26/2023 [1].

= I am proposing OpenSSL be made private along with all dependent = libraries, for the following reasons:
1. More = than a handful of core ports, e.g., security/py-cryptography [2] = [3], still do not support OpenSSL 3.0.
= i. If other dependent ports (like lang/python38, etc) move = to OpenSSL 3, the distributed modules would break on load due to = clashing symbols if the right mix of modules were dlopen=E2=80=99ed in a = specific order (importing ssl, then importing hazmat=E2=80=99s crypto = would fail).
ii. Such ports should be = deprecated/marked broken as I=E2=80=99ve recommended on the 3.0 exp-run = PR [4].
2. OpenSSL 1.1 and 3.0 have = clashing symbols, which makes linking in both libraries at runtime = impossible without resorting to a number of linker tricks hiding the = namespaces using symbol prefixing of public symbols, etc.

The = libraries which would need to be made private are as follows:
= - kerberos
- = libarchive
- libbsnmp
- libfetch = [5]
- = libgeli
- = libldns
- libmp
= - libradius
- libunbound

I realize = I=E2=80=99m jumping to a prescribed solution without additional = discussion, but I=E2=80=99ve been doing offline analysis related to = uplifting code from OpenSSL 1.x to 3.x over the last several months and = this is the general prescribed solution I=E2=80=99ve come to which is = needed for $work. My perspective might have some blind spots and some of = the discussion done over IRC and might need to be rehashed here for = historical reference/to widen the discussion for alternate solutions = that don=E2=80=99t have the degree of tunnel vision which the solution = I=E2=80=99m employing at $work requires.
I=E2=80=99v= e tried to include some of the previously involved parties so they can = chime in.
Thank you,
-Enji

1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853&= nbsp;.
3. The reason why it hasn=E2=80=99t been = upgraded is because newer versions require rustc to build, which = apparently doesn=E2=80=99t work on QEMU builders due to missing = emulation support: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853&= nbsp;. 
4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15<= /a>
5. If I remember correctly, some folks = suggested that making libfetch private wasn=E2=80=99t required since the = only port that required it was ports-mgmt/pkg, but I haven=E2=80=99t = validated this claim.
= --Apple-Mail=_59A391A5-ABC1-4FE9-A7EE-086D06A8BF3D-- --Apple-Mail=_9881111A-489D-436B-924D-4A8CB3A4030F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmRQbX0ACgkQ5JFNMZeD GN6MrxAAmOcqzk3sqazcyIvBXjtV5vvTlvtxeR0LQEd5HP+vfkAf3rJphx52PMuW eVJcRJZTaFJ4L5Zpb6b/FS++gwsJkhGOMpm7iqZG9N0ppCzX02wgCLK1u/iHzcNI W6ZeyT5RbyA9tHIRmsgNcyIeEBrloZmOG6lTE/u+Vmk9rg6TH87qAsUv/0LiqwRn JP4Go03ZiNIQ5FXoAxBEEIiwtaIQ/UNjBO7HKO/+4dTELjVPclbEomijFaIibCxF iSyP3XAxykBI7gm/9njZuQq1aSXRUjsuPhOrdJ4h05WM02uGW3k+U1ObA8kSGMvG Plroh1YxaTOCqcdfgbaYuun5aXMG4O7mOVlPCV7SyddrbyQD/hsvevHf1A3n9mD5 YA25xcCxQVccNubolxrvj/Wx0OhzbXAkXg0f1YQ3yO0xldMT4HJhL5w0gOYFNlvF G3T1TOAt1XWamTqgz1+oP0uys5KsjIPI9c+RVw3C5nhCCwUQw74d8QhQgVso2gvU oKcXFWIdv//f4JbrSMxhXkMmSbTSks7d0120BiNtQcXeh834xWWmgAxiSwoY4s1l OtA7QyG2f64hL/GpOhJ+InxAveoGIU1O1IS+tZDF6LjW9OD+bmyE0JSg8dsNG+8B ynL5wr2UVpeKY9xDZ9WBLg5FmdSYkNJh47BT0mSdd+t7NC/1YG0= =vi49 -----END PGP SIGNATURE----- --Apple-Mail=_9881111A-489D-436B-924D-4A8CB3A4030F-- From nobody Tue May 2 03:47: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 4Q9Qyx3hSSz48PHH for ; Tue, 2 May 2023 03:48:09 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Received: from mail.wilcox-tech.com (mail.wilcox-tech.com [45.32.83.9]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "*.wilcox-tech.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9Qyx0BYWz4Fc8 for ; Tue, 2 May 2023 03:48:08 +0000 (UTC) (envelope-from AWilcox@Wilcox-Tech.com) Authentication-Results: mx1.freebsd.org; none Received: (qmail 13731 invoked from network); 2 May 2023 03:48:20 -0000 Received: from ip98-188-99-66.tu.ok.cox.net (HELO smtpclient.apple) (AWilcox@Wilcox-Tech.com@98.188.99.66) by mail.wilcox-tech.com with ESMTPA; 2 May 2023 03:48:20 -0000 From: "A. Wilcox" Content-Type: multipart/alternative; boundary="Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2" 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 (Mac OS X Mail 16.0 \(3731.400.51.1.1\)) Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Date: Mon, 1 May 2023 22:47:16 -0500 References: To: Enji Cooper , FreeBSD-arch list In-Reply-To: Message-Id: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> X-Mailer: Apple Mail (2.3731.400.51.1.1) X-Rspamd-Queue-Id: 4Q9Qyx0BYWz4Fc8 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:20473, ipnet:45.32.64.0/19, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On May 1, 2023, at 8:55 PM, Enji Cooper wrote: > Hello, > One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL 3.0 into the base system. This is a must because, in short, = OpenSSL 1.1 is no longer supported as of 09/26/2023 [1]. >=20 > I am proposing OpenSSL be made private along with all dependent = libraries, for the following reasons: > 1. More than a handful of core ports, e.g., = security/py-cryptography [2] [3], still do not support OpenSSL 3.0. > i. If other dependent ports (like lang/python38, etc) = move to OpenSSL 3, the distributed modules would break on load due to = clashing symbols if the right mix of modules were dlopen=E2=80=99ed in a = specific order (importing ssl, then importing hazmat=E2=80=99s crypto = would fail). > ii. Such ports should be deprecated/marked broken as = I=E2=80=99ve recommended on the 3.0 exp-run PR [4]. > 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes = linking in both libraries at runtime impossible without resorting to a = number of linker tricks hiding the namespaces using symbol prefixing of = public symbols, etc. >=20 > The libraries which would need to be made private are as = follows: > - kerberos > - libarchive > - libbsnmp > - libfetch [5] > - libgeli > - libldns > - libmp > - libradius > - libunbound >=20 > I realize I=E2=80=99m jumping to a prescribed solution without = additional discussion, but I=E2=80=99ve been doing offline analysis = related to uplifting code from OpenSSL 1.x to 3.x over the last several = months and this is the general prescribed solution I=E2=80=99ve come to = which is needed for $work. My perspective might have some blind spots = and some of the discussion done over IRC and might need to be rehashed = here for historical reference/to widen the discussion for alternate = solutions that don=E2=80=99t have the degree of tunnel vision which the = solution I=E2=80=99m employing at $work requires. > I=E2=80=99ve tried to include some of the previously involved = parties so they can chime in. > Thank you, > -Enji >=20 > 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions require rustc to build, which apparently doesn=E2=80=99t work = on QEMU builders due to missing emulation support: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 .=20 > 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > 5. If I remember correctly, some folks suggested that making libfetch = private wasn=E2=80=99t required since the only port that required it was = ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. Hi Enji (+ arch list), My opinion may not amount to much, but I=E2=80=99m not sure it makes = sense to make it private solely for the sake of allowing ports to keep = going with known insecure software. I think ports should be loudly warning, right now, that they require = OpenSSL 1.x and there should be work with both upstreams and end users = to seek out and migrate to OpenSSL 3. I, with others, have already = begun this work a while back in the Linux world. If the desire is to make these libraries private for future = improvements, or for the ability to swap in other another crypto/TLS = implementation and perform experiments and innovate, then that seems = like it could be a useful tradeoff. However, if it=E2=80=99s just to = allow insecure software to continue to be used, I think that is ill = advised. The global landscape of information security is different and = I think it warrants a different response than maybe it would have in the = past. And it should at least be a consideration to have a loud and = forceful break in the interest of keeping data private and secure. Best, -A. -- A. Wilcox (they/them) SW Engineering: C/C++, DevOps, POSIX Wilcox Technologies Inc. --Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 On May 1, = 2023, at 8:55 PM, Enji Cooper <yaneurabeya@gmail.com> = wrote:
Hello,
One of the must-haves for = 14.0-RELEASE is the introduction of OpenSSL 3.0 into the base system. = This is a must because, in short, OpenSSL 1.1 is no longer supported as = of 09/26/2023 [1].

I am proposing OpenSSL be made = private along with all dependent libraries, for the following = reasons:
1. More than a handful of = core ports, e.g., security/py-cryptography [2] [3], still do not support = OpenSSL 3.0.
i. If other = dependent ports (like lang/python38, etc) move to OpenSSL 3, the = distributed modules would break on load due to clashing symbols if the = right mix of modules were dlopen=E2=80=99ed in a specific order = (importing ssl, then importing hazmat=E2=80=99s crypto would = fail).
= ii. Such ports should be deprecated/marked broken as I=E2=80=99ve = recommended on the 3.0 exp-run PR [4].
= 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes = linking in both libraries at runtime impossible without resorting to a = number of linker tricks hiding the namespaces using symbol prefixing of = public symbols, etc.

The = libraries which would need to be made private are as = follows:
- kerberos
- libarchive
- = libbsnmp
- libfetch = [5]
- libgeli
- libldns
- = libmp
- libradius
- = libunbound

I realize I=E2=80=99m jumping to = a prescribed solution without additional discussion, but I=E2=80=99ve = been doing offline analysis related to uplifting code from OpenSSL 1.x = to 3.x over the last several months and this is the general prescribed = solution I=E2=80=99ve come to which is needed for $work. My perspective = might have some blind spots and some of the discussion done over IRC and = might need to be rehashed here for historical reference/to widen the = discussion for alternate solutions that don=E2=80=99t have the degree of = tunnel vision which the solution I=E2=80=99m employing at $work = requires.
I=E2=80=99ve tried to include = some of the previously involved parties so they can chime = in.
Thank = you,
-Enji

= 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions require rustc to build, which apparently doesn=E2=80=99t work = on QEMU builders due to missing emulation support: https:= //bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . 5. If I remember correctly, some folks suggested that making libfetch = private wasn=E2=80=99t required since the only port that required it was = ports-mgmt/pkg, but I haven=E2=80=99t validated this = claim.


=
Hi Enji (+ arch list),

My opinion = may not amount to much, but I=E2=80=99m not sure it makes sense to make = it private solely for the sake of allowing ports to keep going with = known insecure software.

I think ports should = be loudly warning, right now, that they require OpenSSL 1.x and there = should be work with both upstreams and end users to seek out and migrate = to OpenSSL 3.  I, with others, have already begun this work a while = back in the Linux world.

If the desire is to = make these libraries private for future improvements, or for the ability = to swap in other another crypto/TLS implementation and perform = experiments and innovate, then that seems like it could be a useful = tradeoff. However, if it=E2=80=99s just to allow insecure software to = continue to be used, I think that is ill advised.  The global = landscape of information security is different and I think it warrants a = different response than maybe it would have in the past.  And it = should at least be a consideration to have a loud and forceful break in = the interest of keeping data private and = secure.

Best,
-A.

-= -
A. Wilcox (they/them)
SW Engineering: C/C++, DevOps, = POSIX
Wilcox Technologies Inc.

= --Apple-Mail=_84BEDD47-0B95-486C-8877-9D46FD52B0B2-- From nobody Tue May 2 04:20:30 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 4Q9RhJ72dvz48QZn for ; Tue, 2 May 2023 04:20:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9RhJ4XRTz4HC5; Tue, 2 May 2023 04:20:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683001232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u2XtTMx9nJ2FhoY57jyzeq6ikuMB1XwkOEbG/psgOyw=; b=w0K9pBenLdtCfPg0nseyXrJigvw527eI+RVdBtJloImj0DQ1YRa763nlX/vt5KIvkJfJGu 8MOavRT4nSzFlsvWdzhSr3HnC8bRpfHQpXDNiEcl4QJbGeVy35Q1oNXqxC5sMck1/j6Ws+ OHRLmmH+b15i9bshM8/6vkhimGblbPw3V640GaObh6tiUp5h56UJUeL/Iik6iwKJ8Etfa1 cAObYeMJDtomODmo9tTKfe3RwK9zdO/AWJ9uF/vPF1p489TUgiRiz25ow73hpDsY7QAPzE 7O3/YLelw1FtdhGqp587G1VZK2BdjMiTUkwbeFk6DPqqd37I5eP52sYTrz/wcA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683001232; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=u2XtTMx9nJ2FhoY57jyzeq6ikuMB1XwkOEbG/psgOyw=; b=XdzF1FIYDi09xZg63DfifzSRgUmT4f1pWfZtP8qstiNm81R2/8jmoeu8UqatU6ESE0+j+x HqjnJAYqUO01Pe5UwVY5MLw2FXufekjoRC5xpkgKIyzyEe0W7Z0x0zVfNThO2hzIm4037b oEbUH+b8LZiL7qPNll5laVQzA1NWO8d4z+AsmX0E09dPv29RjhY6QV2t1kP9D7Op5TfpPe cylnyqhMZZBKFdy935/SDSL2RHKpmiuEBwvzRjTmP0QEz2DeGSnhOVcAZYp8Xtjlt1xvzb R4f92K4CvxFsQKSatXO1CKFctRwd9gRVg1T2Rxw6ouBVa/xw2uFj5b904326xQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683001232; a=rsa-sha256; cv=none; b=BjwRY6tnuRcJo3hoWNFu822U0YWt4MwTIDdYKu8atm0itsUiOHtHovqEj/OMM5AbB7KGb3 U/Mgj7ij2tCf1FxMbEUYNyx33ivFyEXtVY2vjWx7+GPvmR3msv1UF5J/cx1p4p/RzNDUzK Faw2Ijw2DvPB1dPwa4Z1dSRrYty6GQ+t8d7PvH/sv6RvBDoSaVinSNi9sBnoSAp7/8wOGV CuaVly41gFSnJL8LmftrsQ9KK5UbIV3C+sy2Bo6l3htLlN3ZuUdRF7ulCFUgj0XUza81I0 l7UhD+pGR2tuq6Rlx0eeEjfuWkf30QXuzU6MsCn3rIdd4OhdzAqMu0jdvb0LAw== Received: from freefall.freebsd.org (pool-96-225-18-219.nwrknj.fios.verizon.net [96.225.18.219]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q9RhJ2kVSz132f; Tue, 2 May 2023 04:20:32 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: Date: Tue, 2 May 2023 00:20:30 -0400 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Content-Language: en-US To: "A. Wilcox" , Enji Cooper , FreeBSD-arch list References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> From: Jung-uk Kim Organization: FreeBSD.org In-Reply-To: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------jhpTvjHUK6kjb3XeiDSZBmXT" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------jhpTvjHUK6kjb3XeiDSZBmXT Content-Type: multipart/mixed; boundary="------------i85JYHwlWG00v69xWg3tIYln"; protected-headers="v1" From: Jung-uk Kim To: "A. Wilcox" , Enji Cooper , FreeBSD-arch list Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> In-Reply-To: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> --------------i85JYHwlWG00v69xWg3tIYln Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjMuIDUuIDEuLCBBLiBXaWxjb3ggd3JvdGU6DQo+IE9uIE1heSAxLCAyMDIzLCBhdCA4 OjU1IFBNLCBFbmppIENvb3BlciA8eWFuZXVyYWJleWFAZ21haWwuY29tPiB3cm90ZToNCj4+ IEhlbGxvLA0KPj4gT25lIG9mIHRoZSBtdXN0LWhhdmVzIGZvciAxNC4wLVJFTEVBU0UgaXMg dGhlIGludHJvZHVjdGlvbiBvZiBPcGVuU1NMIA0KPj4gMy4wIGludG8gdGhlIGJhc2Ugc3lz dGVtLiBUaGlzIGlzIGEgbXVzdCBiZWNhdXNlLCBpbiBzaG9ydCwgT3BlblNTTCANCj4+IDEu MSBpcyBubyBsb25nZXIgc3VwcG9ydGVkIGFzIG9mIDA5LzI2LzIwMjMgWzFdLg0KPj4NCj4+ IEkgYW0gcHJvcG9zaW5nIE9wZW5TU0wgYmUgbWFkZSBwcml2YXRlIGFsb25nIHdpdGggYWxs IGRlcGVuZGVudCANCj4+IGxpYnJhcmllcywgZm9yIHRoZSBmb2xsb3dpbmcgcmVhc29uczoN Cj4+IDEuIE1vcmUgdGhhbiBhIGhhbmRmdWzCoG9mIGNvcmUgcG9ydHMsIGUuZy4sIHNlY3Vy aXR5L3B5LWNyeXB0b2dyYXBoeSANCj4+IFsyXSBbM10sIHN0aWxsIGRvIG5vdCBzdXBwb3J0 IE9wZW5TU0wgMy4wLg0KPj4gaS7CoElmIG90aGVyIGRlcGVuZGVudCBwb3J0cyAobGlrZSBs YW5nL3B5dGhvbjM4LCBldGMpIG1vdmUgdG8gT3BlblNTTCANCj4+IDMsIHRoZSBkaXN0cmli dXRlZCBtb2R1bGVzIHdvdWxkIGJyZWFrIG9uIGxvYWQgZHVlIHRvIGNsYXNoaW5nIHN5bWJv bHMgDQo+PiBpZiB0aGUgcmlnaHQgbWl4IG9mIG1vZHVsZXMgd2VyZSBkbG9wZW7igJllZCBp biBhIHNwZWNpZmljIG9yZGVyIA0KPj4gKGltcG9ydGluZyBzc2wsIHRoZW4gaW1wb3J0aW5n IGhhem1hdOKAmXMgY3J5cHRvIHdvdWxkIGZhaWwpLg0KPj4gaWkuIFN1Y2ggcG9ydHMgc2hv dWxkIGJlIGRlcHJlY2F0ZWQvbWFya2VkIGJyb2tlbiBhcyBJ4oCZdmUgcmVjb21tZW5kZWQg DQo+PiBvbiB0aGUgMy4wIGV4cC1ydW4gUFIgWzRdLg0KPj4gMi7CoE9wZW5TU0wgMS4xIGFu ZCAzLjAgaGF2ZSBjbGFzaGluZyBzeW1ib2xzLCB3aGljaCBtYWtlcyBsaW5raW5nIGluIA0K Pj4gYm90aCBsaWJyYXJpZXMgYXQgcnVudGltZSBpbXBvc3NpYmxlIHdpdGhvdXQgcmVzb3J0 aW5nIHRvIGEgbnVtYmVyIG9mIA0KPj4gbGlua2VyIHRyaWNrcyBoaWRpbmcgdGhlIG5hbWVz cGFjZXMgdXNpbmcgc3ltYm9sIHByZWZpeGluZyBvZiBwdWJsaWMgDQo+PiBzeW1ib2xzLCBl dGMuDQo+Pg0KPj4gVGhlIGxpYnJhcmllcyB3aGljaCB3b3VsZCBuZWVkIHRvIGJlIG1hZGUg cHJpdmF0ZSBhcmUgYXMgZm9sbG93czoNCj4+IC0ga2VyYmVyb3MNCj4+IC0gbGliYXJjaGl2 ZQ0KPj4gLSBsaWJic25tcA0KPj4gLSBsaWJmZXRjaCBbNV0NCj4+IC0gbGliZ2VsaQ0KPj4g LSBsaWJsZG5zDQo+PiAtIGxpYm1wDQo+PiAtIGxpYnJhZGl1cw0KPj4gLSBsaWJ1bmJvdW5k DQo+Pg0KPj4gSSByZWFsaXplIEnigJltIGp1bXBpbmcgdG8gYSBwcmVzY3JpYmVkIHNvbHV0 aW9uIHdpdGhvdXQgYWRkaXRpb25hbCANCj4+IGRpc2N1c3Npb24sIGJ1dCBJ4oCZdmUgYmVl biBkb2luZyBvZmZsaW5lIGFuYWx5c2lzIHJlbGF0ZWQgdG8gdXBsaWZ0aW5nIA0KPj4gY29k ZSBmcm9tIE9wZW5TU0wgMS54IHRvIDMueCBvdmVyIHRoZSBsYXN0IHNldmVyYWwgbW9udGhz IGFuZCB0aGlzIGlzIA0KPj4gdGhlIGdlbmVyYWwgcHJlc2NyaWJlZCBzb2x1dGlvbiBJ4oCZ dmUgY29tZSB0byB3aGljaCBpcyBuZWVkZWQgZm9yIA0KPj4gJHdvcmsuIE15IHBlcnNwZWN0 aXZlIG1pZ2h0IGhhdmUgc29tZSBibGluZCBzcG90cyBhbmQgc29tZSBvZiB0aGUgDQo+PiBk aXNjdXNzaW9uIGRvbmUgb3ZlciBJUkMgYW5kIG1pZ2h0IG5lZWQgdG8gYmUgcmVoYXNoZWQg aGVyZSBmb3IgDQo+PiBoaXN0b3JpY2FsIHJlZmVyZW5jZS90byB3aWRlbiB0aGUgZGlzY3Vz c2lvbiBmb3IgYWx0ZXJuYXRlIHNvbHV0aW9ucyANCj4+IHRoYXQgZG9u4oCZdCBoYXZlIHRo ZSBkZWdyZWUgb2YgdHVubmVsIHZpc2lvbiB3aGljaCB0aGUgc29sdXRpb24gSeKAmW0gDQo+ PiBlbXBsb3lpbmcgYXQgJHdvcmsgcmVxdWlyZXMuDQo+PiBJ4oCZdmUgdHJpZWQgdG8gaW5j bHVkZSBzb21lIG9mIHRoZSBwcmV2aW91c2x5IGludm9sdmVkIHBhcnRpZXMgc28gdGhleSAN Cj4+IGNhbiBjaGltZSBpbi4NCj4+IFRoYW5rIHlvdSwNCj4+IC1FbmppDQo+Pg0KPj4gMS4g aHR0cHM6Ly93d3cub3BlbnNzbC5vcmcvYmxvZy9ibG9nLzIwMjMvMDMvMjgvMS4xLjEtRU9M LyANCj4+IDxodHRwczovL3d3dy5vcGVuc3NsLm9yZy9ibG9nL2Jsb2cvMjAyMy8wMy8yOC8x LjEuMS1FT0wvPg0KPj4gMi4gaHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3No b3dfYnVnLmNnaT9pZD0yNTQ4NTMgDQo+PiA8aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1 Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNTQ4NTM+wqAuDQo+PiAzLiBUaGUgcmVhc29uIHdo eSBpdCBoYXNu4oCZdCBiZWVuIHVwZ3JhZGVkIGlzIGJlY2F1c2UgbmV3ZXIgdmVyc2lvbnMg DQo+PiByZXF1aXJlIHJ1c3RjIHRvIGJ1aWxkLCB3aGljaCBhcHBhcmVudGx5IGRvZXNu4oCZ dCB3b3JrIG9uIFFFTVUgYnVpbGRlcnMgDQo+PiBkdWUgdG8gbWlzc2luZyBlbXVsYXRpb24g c3VwcG9ydDogDQo+PiBodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19i dWcuY2dpP2lkPTI1NDg1MyANCj4+IDxodHRwczovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemls bGEvc2hvd19idWcuY2dpP2lkPTI1NDg1Mz7CoC4NCj4+IDQuIGh0dHBzOi8vYnVncy5mcmVl YnNkLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjU4NDEzI2MxNSANCj4+IDxodHRw czovL2J1Z3MuZnJlZWJzZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTI1ODQxMyNj MTU+DQo+PiA1LiBJZiBJIHJlbWVtYmVyIGNvcnJlY3RseSwgc29tZSBmb2xrcyBzdWdnZXN0 ZWQgdGhhdCBtYWtpbmcgbGliZmV0Y2ggDQo+PiBwcml2YXRlIHdhc27igJl0IHJlcXVpcmVk IHNpbmNlIHRoZSBvbmx5IHBvcnQgdGhhdCByZXF1aXJlZCBpdCB3YXMgDQo+PiBwb3J0cy1t Z210L3BrZywgYnV0IEkgaGF2ZW7igJl0IHZhbGlkYXRlZCB0aGlzIGNsYWltLg0KPiANCj4g DQo+IEhpIEVuamkgKCsgYXJjaCBsaXN0KSwNCj4gDQo+IE15IG9waW5pb24gbWF5IG5vdCBh bW91bnQgdG8gbXVjaCwgYnV0IEnigJltIG5vdCBzdXJlIGl0IG1ha2VzIHNlbnNlIHRvIA0K PiBtYWtlIGl0IHByaXZhdGUgc29sZWx5IGZvciB0aGUgc2FrZSBvZiBhbGxvd2luZyBwb3J0 cyB0byBrZWVwIGdvaW5nIHdpdGggDQo+IGtub3duIGluc2VjdXJlIHNvZnR3YXJlLg0KPiAN Cj4gSSB0aGluayBwb3J0cyBzaG91bGQgYmUgbG91ZGx5IHdhcm5pbmcsIHJpZ2h0IG5vdywg dGhhdCB0aGV5IHJlcXVpcmUgDQo+IE9wZW5TU0wgMS54IGFuZCB0aGVyZSBzaG91bGQgYmUg d29yayB3aXRoIGJvdGggdXBzdHJlYW1zIGFuZCBlbmQgdXNlcnMgDQo+IHRvIHNlZWsgb3V0 IGFuZCBtaWdyYXRlIHRvIE9wZW5TU0wgMy4gwqBJLCB3aXRoIG90aGVycywgaGF2ZSBhbHJl YWR5IA0KPiBiZWd1biB0aGlzIHdvcmsgYSB3aGlsZSBiYWNrIGluIHRoZSBMaW51eCB3b3Js ZC4NCj4gDQo+IElmIHRoZSBkZXNpcmUgaXMgdG8gbWFrZSB0aGVzZSBsaWJyYXJpZXMgcHJp dmF0ZSBmb3IgZnV0dXJlIA0KPiBpbXByb3ZlbWVudHMsIG9yIGZvciB0aGUgYWJpbGl0eSB0 byBzd2FwIGluIG90aGVyIGFub3RoZXIgY3J5cHRvL1RMUyANCj4gaW1wbGVtZW50YXRpb24g YW5kIHBlcmZvcm0gZXhwZXJpbWVudHMgYW5kIGlubm92YXRlLCB0aGVuIHRoYXQgc2VlbXMg DQo+IGxpa2UgaXQgY291bGQgYmUgYSB1c2VmdWwgdHJhZGVvZmYuIEhvd2V2ZXIsIGlmIGl0 4oCZcyBqdXN0IHRvIGFsbG93IA0KPiBpbnNlY3VyZSBzb2Z0d2FyZSB0byBjb250aW51ZSB0 byBiZSB1c2VkLCBJIHRoaW5rIHRoYXQgaXMgaWxsIGFkdmlzZWQuIA0KPiAgwqBUaGUgZ2xv YmFsIGxhbmRzY2FwZSBvZiBpbmZvcm1hdGlvbiBzZWN1cml0eSBpcyBkaWZmZXJlbnQgYW5k IEkgdGhpbmsgDQo+IGl0IHdhcnJhbnRzIGEgZGlmZmVyZW50IHJlc3BvbnNlIHRoYW4gbWF5 YmUgaXQgd291bGQgaGF2ZSBpbiB0aGUgcGFzdC4gDQo+ICDCoEFuZCBpdCBzaG91bGQgYXQg bGVhc3QgYmUgYSBjb25zaWRlcmF0aW9uIHRvIGhhdmUgYSBsb3VkIGFuZCBmb3JjZWZ1bCAN Cj4gYnJlYWsgaW4gdGhlIGludGVyZXN0IG9mIGtlZXBpbmcgZGF0YSBwcml2YXRlIGFuZCBz ZWN1cmUuDQoNCisxDQoNCkp1bmctdWsgS2ltDQo= --------------i85JYHwlWG00v69xWg3tIYln-- --------------jhpTvjHUK6kjb3XeiDSZBmXT Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmRQj44FAwAAAAAACgkQfJ+WJvzb8UbZ UAf+JKHIRDlXagtcYmetFBYCBA+AiHwedRoKp7o8jAzU8GQvsSVeHOZ3rVmwB+3uROom69G20qLF X9Ljf8BPGi37xMU1+grthUAIuxc7D3Lue+jZeiAmVMzRHEhFCw+spjdefsxQRhok6Aj1uG4pjBi+ 7d09GgN2WAAACZRD+piWM3ES6YxHiVW3OwIFFJnXNs0vW8UIyAoPAXiUNqRZJzJgP8Z+vywyumaE RPxwYuZC75bCjIuiNrV5U3HrsXZxmnztA6qFP+Mn5JEGEk21/YWb42z0mAG1fAD7PGniz7c7G4aV pXvjguBm60D8hPtTHNo/gz2YWmx0ZK/VNUWl2SL3OA== =oUSv -----END PGP SIGNATURE----- --------------jhpTvjHUK6kjb3XeiDSZBmXT-- From nobody Tue May 2 07:28:51 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 4Q9Wsc0BKhz48dBv for ; Tue, 2 May 2023 07:28:52 +0000 (UTC) (envelope-from rene@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9Wsb6nPsz4YMx; Tue, 2 May 2023 07:28:51 +0000 (UTC) (envelope-from rene@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683012532; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fsQTxqTpMPcc6x/OWlwRY9u/PZuxToThpthfxMpg67A=; b=g5Ot0Jll+bifVYFZlg4v9jjpqVCyhsCJMncNKZeJ5mNkRgE7EClp+P30jNS+RltiS2m/qW JchoZPDNTboGyyvlcY7PfePTlSv0Bb0ZlXMWhKm6j3MmaZx49JWOO2G82oAUzLARZKzR5b ZISz5JNiQdHAiJAFgH+ApFZ+TDz74gecQyfOlZQrJ2Wc6eMunE7QI8pA2qjjwYf6vIfH47 uMsL1Zq9H8aOVpAbsy94l/SUvlamJmlFNMpO8IQkxbQPM9hTNzK57pefz619wblmezoqxJ GDe40Li6JLrzAB6LOb+ET/xAn6+PDAA9jMEyNMumL+FEfiheN1RwU9sZr9rL4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683012532; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=fsQTxqTpMPcc6x/OWlwRY9u/PZuxToThpthfxMpg67A=; b=vj3nlYj8fGFY0IyEajiSq/P0peK2MoVo3MamQ49l/e33Yvg4HwspjyHUJtpDUly3G/GUtE VkVGVZaD1P/UQJayF96hQa9WETILKJTOaAcAozsfFgtGoR46lDxDOFpBtbC8UaiyKnhafz SRVx2ho6egdC1CURMjxuKD7wjaipD42fMaBGsNreKYg8fw3hKadAZkg1Q4xi4R9AWDmwLT cpyXZT0hZxWZbuE+yDMpO2lR6HMH2Vbz9SoBcOu8Gpl12d6u7PhPe1XEfWuUTZdCTjoIW1 tB/lSR4HPTfY5nBK1R6Aiaf9h70i7aoMC2hM1+gW8Cor47L7z7KnpPsAIr7XHA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683012532; a=rsa-sha256; cv=none; b=LcWSGgv0WINaHpjrcqpmFnV3gMI+Xh3MMwew+ma1R48lTImfzypDO3jA7yi3nLbSZSy1J5 xI+/Jnh81Nhp8/6YGZ9Cfoikeu9NyAQeCK79F1PtDCVtJftVhQurnn/01VyGwp5vFeWDYC 9CbuLkMZn43LBHEnf+27UcS7BGla6jhMZsnOX3YMhCU6snByaVD8Si9rQAKFc+WclNmmf8 nDGP1viXO9yelJw7kuVyXNGYmzX5NlcdwBX5DQ1WfLbZBkNIXVYmM8CbzP1YbfebOP4n9F pB3lToiO2OszOG6vfUqz6vEzZsEqbcErESPO5pX+8hiVgBlySic8MvQJEYWbqg== Received: by freefall.freebsd.org (Postfix, from userid 1185) id CDC0CD485; Tue, 2 May 2023 07:28:51 +0000 (UTC) Date: Tue, 2 May 2023 07:28:51 +0000 From: Rene Ladan To: Jung-uk Kim Cc: "A. Wilcox" , Enji Cooper , FreeBSD-arch list Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Message-ID: References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> 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 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-ThisMailContainsUnwantedMimeParts: N On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote: > On 23. 5. 1., A. Wilcox wrote: > > On May 1, 2023, at 8:55 PM, Enji Cooper wrote: > >> Hello, > >> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL > >> 3.0 into the base system. This is a must because, in short, OpenSSL > >> 1.1 is no longer supported as of 09/26/2023 [1]. > >> > >> I am proposing OpenSSL be made private along with all dependent > >> libraries, for the following reasons: > >> 1. More than a handful of core ports, e.g., security/py-cryptography > >> [2] [3], still do not support OpenSSL 3.0. > >> i. If other dependent ports (like lang/python38, etc) move to OpenSSL > >> 3, the distributed modules would break on load due to clashing symbols > >> if the right mix of modules were dlopen’ed in a specific order > >> (importing ssl, then importing hazmat’s crypto would fail). > >> ii. Such ports should be deprecated/marked broken as I’ve recommended > >> on the 3.0 exp-run PR [4]. > >> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in > >> both libraries at runtime impossible without resorting to a number of > >> linker tricks hiding the namespaces using symbol prefixing of public > >> symbols, etc. > >> > >> The libraries which would need to be made private are as follows: > >> - kerberos > >> - libarchive > >> - libbsnmp > >> - libfetch [5] > >> - libgeli > >> - libldns > >> - libmp > >> - libradius > >> - libunbound > >> > >> I realize I’m jumping to a prescribed solution without additional > >> discussion, but I’ve been doing offline analysis related to uplifting > >> code from OpenSSL 1.x to 3.x over the last several months and this is > >> the general prescribed solution I’ve come to which is needed for > >> $work. My perspective might have some blind spots and some of the > >> discussion done over IRC and might need to be rehashed here for > >> historical reference/to widen the discussion for alternate solutions > >> that don’t have the degree of tunnel vision which the solution I’m > >> employing at $work requires. > >> I’ve tried to include some of the previously involved parties so they > >> can chime in. > >> Thank you, > >> -Enji > >> > >> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > >> > >> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853 > >>  . > >> 3. The reason why it hasn’t been upgraded is because newer versions > >> require rustc to build, which apparently doesn’t work on QEMU builders > >> due to missing emulation support: > >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254853 > >>  . > >> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=258413#c15 > >> > >> 5. If I remember correctly, some folks suggested that making libfetch > >> private wasn’t required since the only port that required it was > >> ports-mgmt/pkg, but I haven’t validated this claim. > > > > > > Hi Enji (+ arch list), > > > > My opinion may not amount to much, but I’m not sure it makes sense to > > make it private solely for the sake of allowing ports to keep going with > > known insecure software. > > > > I think ports should be loudly warning, right now, that they require > > OpenSSL 1.x and there should be work with both upstreams and end users > > to seek out and migrate to OpenSSL 3.  I, with others, have already > > begun this work a while back in the Linux world. > > > > If the desire is to make these libraries private for future > > improvements, or for the ability to swap in other another crypto/TLS > > implementation and perform experiments and innovate, then that seems > > like it could be a useful tradeoff. However, if it’s just to allow > > insecure software to continue to be used, I think that is ill advised. > >  The global landscape of information security is different and I think > > it warrants a different response than maybe it would have in the past. > >  And it should at least be a consideration to have a loud and forceful > > break in the interest of keeping data private and secure. > > +1 > > Jung-uk Kim (Randomly replying) Ports upstreams will probably take their time (if ever) to migrate off OpenSSL 1.X, as we have seen with Python 2.7. Having a private library for OpenSSL in base might also simply the SSL framework in ports (?) René (personal hat only) From nobody Tue May 2 07:39:32 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 4Q9X6n0P9Sz48dhb for ; Tue, 2 May 2023 07:40:17 +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) client-signature ECDSA (P-256)) (Client CN "mailgate.leidinger.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9X6m5rGPz4b3Z for ; Tue, 2 May 2023 07:40:16 +0000 (UTC) (envelope-from Alexander@leidinger.net) Authentication-Results: mx1.freebsd.org; none Date: Tue, 02 May 2023 09:39:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=leidinger.net; s=outgoing-alex; t=1683013211; 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; bh=yZIsk9R+ZFtf2XS/uJz8XzibpTJ3zz4OTY2KJIDT/P4=; b=CnUkZh9FH0EEq1dSqtgm8q2+eivx+82ZAdZsEGgaQ63PW+5NrpIUoCWdrdysdKD6y2RFGb JOr/pDZgve+1iQt15ijqLafSqoqDMZrm4xmaahhDUY0GDceIgEow8T16SjJ4pF1tlbV0aK dIWBJLFXXCZCxaChDr19BsKT39ZJuBD8xouV8lhUkkNm6XxJwGhvrYkdxSUGAGX8S1F8oZ Ezi/khDRmuCPqDeezwBvPLNT2Qpkg7t3dxWUiay7SuWIe3XPj3mEgG+mhJ6CHtP9/Pj8mF Pl1gpgJ+iR7IZOLw43/Xyvedl9HJ7gQi321xzAB5Pi2KvwNFr5x4O82J9WUkRg== Message-ID: <20230502093932.Horde.uHWwvXLE_HzfiMtFPj7-DHc@webmail.leidinger.net> From: Alexander Leidinger To: Enji Cooper Cc: FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc In-Reply-To: Accept-Language: de,en Content-Type: multipart/signed; boundary="=_JAofPRg7LCogb4zADovpHuB"; 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: 4Q9X6m5rGPz4b3Z 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. --=_JAofPRg7LCogb4zADovpHuB Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Quoting Enji Cooper (from Mon, 1 May 2023=20=20 18:55:09=20-0700): > Hello, > One of the must-haves for 14.0-RELEASE is the=20=20 >=20introduction of OpenSSL 3.0 into the base system. This is a must=20=20 >=20because, in short, OpenSSL 1.1 is no longer supported as of=20=20 >=2009/26/2023 [1]. > =C2=A0 > I am proposing OpenSSL be made private along with all dependent=20= =20 >=20libraries, for the following reasons: As doing that requires some changes to ports too, I'm repeating (a=20=20 short=20gist of it) my opinion which I voiced in the other thread about=20= =20 OpenSSL: =20 - any solution to ports needs to keep in mind, that we have 13.x=20=20 (with=20OpenSSL 1.1.1) supported for a while, which means we will have=20= =20 conditionals=20in ports on the OpenSSL version and visibility of the=20=20 basesystem=20libs anyway (people working in making those libs private=20=20 need=20to touch ports, and with the focus on making them private we need=20= =20 to=20keep in mind that we have a supported stable branch where they are=20= =20 not=20private) - as such making those libs private in 14 is orthogonal to the issue=20= =20 at=20hand and could be worked on in parallel (as the topic here are=20=20 making=20the libs private, I only want to make this fact explicit=20=20 instead=20of having it implicit in between the lines of your text) - we will have hickups in the ports tree regarding this (sometimes=20=20 on=2013.x, sometimes in -current, sometimes in both) and personally I=20=20 wouldn't=20mind if we declare the main branch of ports temporary as a=20=20 work=20in progress of the OpenSSL migration and go ahead step by step=20=20 there=20(mention in src-UPDATING and ports-UPDATING that we transition=20= =20 to=20OpenSSL 3 and the tree is "unstable" and people should switch to=20=20 the=20quarterly branch until further notice if they want to be sure to=20= =20 get=20a buildable ports tree) Bye, Alexander. --=20 http://www.Leidinger.net=20Alexander@Leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.org netchild@FreeBSD.org : PGP 0x8F31830F9F2772BF --=_JAofPRg7LCogb4zADovpHuB Content-Type: application/pgp-signature Content-Description: Digitale PGP-Signatur Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIzBAABCAAdFiEER9UlYXp1PSd08nWXEg2wmwP42IYFAmRQvjMACgkQEg2wmwP4 2Ia1GQ/9GVAyBUjNaF6B1xezkamuBJHN3DOU4EKplIf/rVEF9+GLtkwwhAtwaIUs y6kq7Zlb+NKHIPAzc4lYMJ0vYp9Tlfsvt7sW5R61ny5v94bUlc4yBoewWZ7Zmxql G2q/kueyHNpDty1Nl2dLSkaVOZtREfKvqe3nIOHViZ2P2kIddRC4Ruct9QGZpn1T OVjNYbuaS2wV4/5LTHSxNkXLzhbeqzxe+wGxPlPF8I5PyXdS2Bj8l4ugMxuwacO6 bMcMGWYN+qfAuU9c/xtlDxClkvDdDPa571yI0mMwAqcO1qW8W21yVuAW1LSMNz0g 0HP3+sKieE3/LwIYOZdrP+x1b16+1A9RAjtulnfa26kzDx6CFhISabl20ay5oIK4 7TByVIIPWohUlcPeYZInFC7mqlgFChRb42Eil9DmWmMKQYK8E1k/kmLT6eZrmy7s zsW0OlDVYRXJFOFBbqwFaai0l4hZKjVeabe4MTES/kqU8CSBJkPM0mBwk45ms4SH sbY00ONhfnYc6VF1YaXy84IRfyJ7/NfICO5nrjMxTaKU+Q3/E98P8FTOz7Bc2Hau D+bcSUw1VEdNGa8OSeFyrwaRD0gh8UaCxj9q/VlD8P9drcTWaRQEmPps645nGLwt skNZh9wm+c7yPi7eA0NJ3Gal4ttXxsiwBQpvMCGqZ9e3ozqMo/0= =SPLR -----END PGP SIGNATURE----- --=_JAofPRg7LCogb4zADovpHuB-- From nobody Tue May 2 08:13:09 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 4Q9Xrr5ZzWz48gP6 for ; Tue, 2 May 2023 08:13:16 +0000 (UTC) (envelope-from cglogic@protonmail.com) Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9Xrq4hDdz3D1b for ; Tue, 2 May 2023 08:13:15 +0000 (UTC) (envelope-from cglogic@protonmail.com) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protonmail.com header.s=protonmail3 header.b=mnxWjGKK; spf=pass (mx1.freebsd.org: domain of cglogic@protonmail.com designates 185.70.40.140 as permitted sender) smtp.mailfrom=cglogic@protonmail.com; dmarc=pass (policy=quarantine) header.from=protonmail.com Date: Tue, 02 May 2023 08:13:09 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1683015191; x=1683274391; bh=UyYMCRmixXWRzdgD0koRnFhhY3mssclCgGH5Hr0yy84=; h=Date:To:From:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=mnxWjGKKLurhiiLyamaWRiECtZELh0TsHGOL2KkapA1VU/eOWr6KZD2gAyv+ZirtV qGB55a5jt76/9/p+dW6denx7U8OM8b4W0R7BwbSEYgNBISvKgxCKOPMfHV7s3v7PXr 17/5KJQqZOLCx4TddV/mvVgeriVtY4MZlsxHTuHNWRBY6xSYrSpVgU6yukn+BnYAcS 6r2l8Y1QfqhWLkhIcU/VKYa4HG4UdH7AAKgjZTTu6cweY+MbQwD1q4xL1LmrNs0oAt szrgDeMki2hOu1oaeiQ3SZBoD7SdISWnFO3iFPd2+H3dOxLwJhYoLvVHwqiOOSAvX1 Hvz3azi3uKNKg== To: FreeBSD-arch list From: cglogic Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Message-ID: In-Reply-To: References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> Feedback-ID: 25313618:user:proton 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 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [-3.19 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[protonmail.com,quarantine]; R_DKIM_ALLOW(-0.20)[protonmail.com:s=protonmail3]; R_SPF_ALLOW(-0.20)[+ip4:185.70.40.0/24]; NEURAL_HAM_SHORT(-0.19)[-0.187]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[protonmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+]; RCVD_COUNT_ZERO(0.00)[0]; ASN(0.00)[asn:62371, ipnet:185.70.40.0/24, country:CH]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[protonmail.com:+]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FREEMAIL_FROM(0.00)[protonmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[185.70.40.140:from] X-Rspamd-Queue-Id: 4Q9Xrq4hDdz3D1b X-Spamd-Bar: --- X-ThisMailContainsUnwantedMimeParts: N On Tuesday, May 2nd, 2023 at 10:28 AM, Rene Ladan wrote: > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote: >=20 > > On 23. 5. 1., A. Wilcox wrote: > >=20 > > > On May 1, 2023, at 8:55 PM, Enji Cooper yaneurabeya@gmail.com wrote: > > >=20 > > > > Hello, > > > > One of the must-haves for 14.0-RELEASE is the introduction of OpenS= SL > > > > 3.0 into the base system. This is a must because, in short, OpenSSL > > > > 1.1 is no longer supported as of 09/26/2023 [1]. > > > >=20 > > > > I am proposing OpenSSL be made private along with all dependent > > > > libraries, for the following reasons: > > > > 1. More than a handful of core ports, e.g., security/py-cryptograph= y > > > > [2] [3], still do not support OpenSSL 3.0. > > > > i. If other dependent ports (like lang/python38, etc) move to OpenS= SL > > > > 3, the distributed modules would break on load due to clashing symb= ols > > > > if the right mix of modules were dlopen=E2=80=99ed in a specific or= der > > > > (importing ssl, then importing hazmat=E2=80=99s crypto would fail). > > > > ii. Such ports should be deprecated/marked broken as I=E2=80=99ve r= ecommended > > > > on the 3.0 exp-run PR [4]. > > > > 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking i= n > > > > both libraries at runtime impossible without resorting to a number = of > > > > linker tricks hiding the namespaces using symbol prefixing of publi= c > > > > symbols, etc. > > > >=20 > > > > The libraries which would need to be made private are as follows: > > > > - kerberos > > > > - libarchive > > > > - libbsnmp > > > > - libfetch [5] > > > > - libgeli > > > > - libldns > > > > - libmp > > > > - libradius > > > > - libunbound > > > >=20 > > > > I realize I=E2=80=99m jumping to a prescribed solution without addi= tional > > > > discussion, but I=E2=80=99ve been doing offline analysis related to= uplifting > > > > code from OpenSSL 1.x to 3.x over the last several months and this = is > > > > the general prescribed solution I=E2=80=99ve come to which is neede= d for > > > > $work. My perspective might have some blind spots and some of the > > > > discussion done over IRC and might need to be rehashed here for > > > > historical reference/to widen the discussion for alternate solution= s > > > > that don=E2=80=99t have the degree of tunnel vision which the solut= ion I=E2=80=99m > > > > employing at $work requires. > > > > I=E2=80=99ve tried to include some of the previously involved parti= es so they > > > > can chime in. > > > > Thank you, > > > > -Enji > > > >=20 > > > > 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > > > https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > > > 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > > > > 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions > > > > require rustc to build, which apparently doesn=E2=80=99t work on QE= MU builders > > > > due to missing emulation support: > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > > > > 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > > > > 5. If I remember correctly, some folks suggested that making libfet= ch > > > > private wasn=E2=80=99t required since the only port that required i= t was > > > > ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. > > >=20 > > > Hi Enji (+ arch list), > > >=20 > > > My opinion may not amount to much, but I=E2=80=99m not sure it makes = sense to > > > make it private solely for the sake of allowing ports to keep going w= ith > > > known insecure software. > > >=20 > > > I think ports should be loudly warning, right now, that they require > > > OpenSSL 1.x and there should be work with both upstreams and end user= s > > > to seek out and migrate to OpenSSL 3. I, with others, have already > > > begun this work a while back in the Linux world. > > >=20 > > > If the desire is to make these libraries private for future > > > improvements, or for the ability to swap in other another crypto/TLS > > > implementation and perform experiments and innovate, then that seems > > > like it could be a useful tradeoff. However, if it=E2=80=99s just to = allow > > > insecure software to continue to be used, I think that is ill advised= . > > > The global landscape of information security is different and I think > > > it warrants a different response than maybe it would have in the past= . > > > And it should at least be a consideration to have a loud and forceful > > > break in the interest of keeping data private and secure. > >=20 > > +1 > >=20 > > Jung-uk Kim >=20 >=20 > (Randomly replying) >=20 > Ports upstreams will probably take their time (if ever) to migrate off > OpenSSL 1.X, as we have seen with Python 2.7. Having a private library > for OpenSSL in base might also simply the SSL framework in ports (?) >=20 > Ren=C3=A9 (personal hat only) (Randomly replying) Hello. Personally I think that all base libs presented in ports should be private. As example: ncurses. Some ports have option to select base/ports to use. Some unconditionally require ncurses from ports. Some will be linked with ncurses from ports if it installed, otherwise ncur= ses from base. Some unconditionally linked with base version. And when some library linked with base ncurses and it used by another port = that linked with ncurses from ports we can see a binary that requires ncurses fr= om base AND ncurses from ports at the same time. Some times it leads to issues= . - Oleh From nobody Tue May 2 09:59:32 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 4Q9bCl32Zfz48mwq for ; Tue, 2 May 2023 09:59:47 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Received: from mail-lf1-f41.google.com (mail-lf1-f41.google.com [209.85.167.41]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9bCl18gZz3ML0; Tue, 2 May 2023 09:59:47 +0000 (UTC) (envelope-from antoine.brodin.freebsd@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f41.google.com with SMTP id 2adb3069b0e04-4f00d3f98deso27197368e87.0; Tue, 02 May 2023 02:59:47 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683021584; x=1685613584; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=rTr2vBseNBG0nSH3K4+GbiwmX/mrMvXFwHeROCW+Ivo=; b=mHLtj3++CqRYtBJMt7FNmj+Bdjjvo4WlN/0v+IXVqxuKf+u5li8U2moJWA7Y07Apij TnkqmojObuYd281vSMQPL6OiXsW6UK9WSDTe4wviAIAESusZf0NA+Zws+/71aZM+ft1+ b7VIXNbpTR5TDCpTPrtQxEBHhu3NftBmotsMcg3w+AQ+WpeHRejOHJM+nCqrfUfjRKXJ 8y0cSFTlEk7YE1inAC/kW9TOohnrD5kD+fPHMabwHEIxX1B4avaeGgdorMECMv/JNW7c gykCK+TqCkJrTw0wPdWF//eCb5DOK8nTghpSHc/iZILm+fjJfdN9SWFpd79LT7ioLPKh ftAw== X-Gm-Message-State: AC+VfDw+1l+ccIeAW5SDOy/zyRcuCGT/ay1mXqEXUCIdEDSD5W7S7RXo bLBI+mHcMIXH+VuvdBpwW5sPtML01Y4w0X1uUFQXrX4S X-Google-Smtp-Source: ACHHUZ45001mzxEwR+YfX3s9isQ7Y6YAFnGlfUGA8YDUaH8yEjvDAEPP1qihfPyMKijyCIFTntq6rnS1g5IkLLm6zyA= X-Received: by 2002:a2e:a48b:0:b0:2a8:e765:16e5 with SMTP id h11-20020a2ea48b000000b002a8e76516e5mr5223802lji.25.1683021584449; Tue, 02 May 2023 02:59:44 -0700 (PDT) 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 References: In-Reply-To: From: Antoine Brodin Date: Tue, 2 May 2023 09:59:32 +0000 Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc To: Enji Cooper Cc: FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4Q9bCl18gZz3ML0 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; TAGGED_FROM(0.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper = wrote: > > Hello, > One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3.0= into the base system. This is a must because, in short, OpenSSL 1.1 is no = longer supported as of 09/26/2023 [1]. > > I am proposing OpenSSL be made private along with all dependent libraries= , for the following reasons: > 1. More than a handful of core ports, e.g., security/py-cryptography [2] = [3], still do not support OpenSSL 3.0. > i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, = the distributed modules would break on load due to clashing symbols if the = right mix of modules were dlopen=E2=80=99ed in a specific order (importing = ssl, then importing hazmat=E2=80=99s crypto would fail). > ii. Such ports should be deprecated/marked broken as I=E2=80=99ve recomme= nded on the 3.0 exp-run PR [4]. > 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in both= libraries at runtime impossible without resorting to a number of linker tr= icks hiding the namespaces using symbol prefixing of public symbols, etc. > > The libraries which would need to be made private are as follows: > - kerberos > - libarchive > - libbsnmp > - libfetch [5] > - libgeli > - libldns > - libmp > - libradius > - libunbound In my opinion this is a huge amount of work a few weeks before the release. Focusing on updating OpenSSL and those core ports may be simpler. Antoine > I realize I=E2=80=99m jumping to a prescribed solution without additional= discussion, but I=E2=80=99ve been doing offline analysis related to uplift= ing code from OpenSSL 1.x to 3.x over the last several months and this is t= he general prescribed solution I=E2=80=99ve come to which is needed for $wo= rk. My perspective might have some blind spots and some of the discussion d= one over IRC and might need to be rehashed here for historical reference/to= widen the discussion for alternate solutions that don=E2=80=99t have the d= egree of tunnel vision which the solution I=E2=80=99m employing at $work re= quires. > I=E2=80=99ve tried to include some of the previously involved parties so = they can chime in. > Thank you, > -Enji > > 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > 3. The reason why it hasn=E2=80=99t been upgraded is because newer versio= ns require rustc to build, which apparently doesn=E2=80=99t work on QEMU bu= ilders due to missing emulation support: https://bugs.freebsd.org/bugzilla/= show_bug.cgi?id=3D254853 . > 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > 5. If I remember correctly, some folks suggested that making libfetch pri= vate wasn=E2=80=99t required since the only port that required it was ports= -mgmt/pkg, but I haven=E2=80=99t validated this claim. From nobody Tue May 2 13:42:22 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 4Q9h8q0bMmz490tX for ; Tue, 2 May 2023 13:42:35 +0000 (UTC) (envelope-from crest@rlwinm.de) Received: from mail.rlwinm.de (mail.rlwinm.de [138.201.35.217]) (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 4Q9h8n3y2Yz41pl for ; Tue, 2 May 2023 13:42:33 +0000 (UTC) (envelope-from crest@rlwinm.de) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of crest@rlwinm.de designates 138.201.35.217 as permitted sender) smtp.mailfrom=crest@rlwinm.de; dmarc=none Received: from [192.168.178.53] (119-101-142-46.pool.kielnet.net [46.142.101.119]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mail.rlwinm.de (Postfix) with ESMTPSA id C3FA822B7D for ; Tue, 2 May 2023 13:42:23 +0000 (UTC) Content-Type: multipart/alternative; boundary="------------dssLZMj1Lmz3aVd33p91GgL3" Message-ID: Date: Tue, 2 May 2023 15:42:22 +0200 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc To: freebsd-arch@freebsd.org References: Content-Language: en-US From: Jan Bramkamp In-Reply-To: X-Spamd-Result: default: False [-0.85 / 15.00]; NEURAL_HAM_SHORT(-0.79)[-0.793]; NEURAL_SPAM_LONG(0.77)[0.775]; NEURAL_HAM_MEDIUM(-0.53)[-0.531]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:24940, ipnet:138.201.0.0/16, country:DE]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_VIA_SMTP_AUTH(0.00)[]; DMARC_NA(0.00)[rlwinm.de]; RCPT_COUNT_ONE(0.00)[1]; MID_RHS_MATCH_FROM(0.00)[]; ARC_NA(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4Q9h8n3y2Yz41pl X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N This is a multi-part message in MIME format. --------------dssLZMj1Lmz3aVd33p91GgL3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 02.05.23 03:55, Enji Cooper wrote: > Hello, > One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL > 3.0 into the base system. This is a must because, in short, OpenSSL > 1.1 is no longer supported as of 09/26/2023 [1]. > > I am proposing OpenSSL be made private along with all dependent > libraries, for the following reasons: > 1. More than a handful of core ports, e.g., security/py-cryptography > [2] [3], still do not support OpenSSL 3.0. > i. If other dependent ports (like lang/python38, etc) move to OpenSSL > 3, the distributed modules would break on load due to clashing symbols > if the right mix of modules were dlopen’ed in a specific order > (importing ssl, then importing hazmat’s crypto would fail). > ii. Such ports should be deprecated/marked broken as I’ve recommended > on the 3.0 exp-run PR [4]. > 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in > both libraries at runtime impossible without resorting to a number of > linker tricks hiding the namespaces using symbol prefixing of public > symbols, etc. > > The libraries which would need to be made private are as follows: > - kerberos > - libarchive > - libbsnmp > - libfetch [5] > - libgeli > - libldns > - libmp > - libradius > - libunbound How does this interact with PAM and NSS? According to my understanding both PAM and NSS work by loading modules as shared libs into the process using them. As a quick test I ran ldd against the PAM modules included in the FreeBSD 13.2 base system and found a lot of them (pam_krb5, pam_ksu, pam_passwdqc, pam_radius, pam_ssh, pam_unix and pam_zfs_key) depend on the base system OpenSSL. Almost all PAM configurations will (try to) used at least one of these modules. As far as I can tell the NSS "modules" available in base are all implemented by libc and don't load the base OpenSSL (at runtime). The same problem would also apply in the reverse direction with PAM and NSS modules loading OpenSSL from ports into services included in base using the base OpenSSL (e.g. sshd). Are there other mechanisms to watch out for that combine shared libs from base and ports at runtime? Are there maintainable solutions in both directions? --------------dssLZMj1Lmz3aVd33p91GgL3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit


On 02.05.23 03:55, Enji Cooper wrote:
Hello,
One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3.0 into the base system. This is a must because, in short, OpenSSL 1.1 is no longer supported as of 09/26/2023 [1].

I am proposing OpenSSL be made private along with all dependent libraries, for the following reasons:
1. More than a handful of core ports, e.g., security/py-cryptography [2] [3], still do not support OpenSSL 3.0.
i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, the distributed modules would break on load due to clashing symbols if the right mix of modules were dlopen’ed in a specific order (importing ssl, then importing hazmat’s crypto would fail).
ii. Such ports should be deprecated/marked broken as I’ve recommended on the 3.0 exp-run PR [4].
2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in both libraries at runtime impossible without resorting to a number of linker tricks hiding the namespaces using symbol prefixing of public symbols, etc.

The libraries which would need to be made private are as follows:
- kerberos
- libarchive
- libbsnmp
- libfetch [5]
- libgeli
- libldns
- libmp
- libradius
- libunbound

How does this interact with PAM and NSS? According to my understanding both PAM and NSS work by loading modules as shared libs into the process using them.

As a quick test I ran ldd against the PAM modules included in the FreeBSD 13.2 base system and found a lot of them (pam_krb5, pam_ksu, pam_passwdqc, pam_radius, pam_ssh, pam_unix and pam_zfs_key) depend on the base system OpenSSL. Almost all PAM configurations will (try to) used at least one of these modules. As far as I can tell the NSS "modules" available in base are all implemented by libc and don't load the base OpenSSL (at runtime).

The same problem would also apply in the reverse direction with PAM and NSS modules loading OpenSSL from ports into services included in base using the base OpenSSL (e.g. sshd).

Are there other mechanisms to watch out for that combine shared libs from base and ports at runtime? Are there maintainable solutions in both directions?

--------------dssLZMj1Lmz3aVd33p91GgL3-- From nobody Tue May 2 14:42:32 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 4Q9jV13PF8z4933g for ; Tue, 2 May 2023 14:42:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9jV12z9nz4B1S; Tue, 2 May 2023 14:42:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683038553; 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=da0kfw7ybyi43BC9VcZI7r8L/09VtET5q7Nm9pBVIaw=; b=B746OL/fSVnHUZx4CH4gjU4KejZf02QQfI3avNxNJ622OLr2tNURowQgWWP1uAI4NEQ/5R UYSNaRBsp1pLA8Yw5PPgb2+Tv6+8lC5SdHvuMms0JBd7CTOj5+icmnVmtR9MvKgPI/wxaH DZFFUHJ/fLCM2JhP+DsLbkDzHMJoC3rUXsh9wQGSa82L7qcP4D+699S3Izxe1YQu61bcg0 saMYkHUWxskE89O3WmDk+rxZOoNRbuh9t6U9CcX4j5Z/5teD4YxM8kIpNOPYb5JY4DCouz gyF83aZhA6J4UL+B4rERymCaWemMfO3vMCACRg8XY0r6vTPJezkE1ySQyRNcrQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683038553; 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=da0kfw7ybyi43BC9VcZI7r8L/09VtET5q7Nm9pBVIaw=; b=qI+Z0jHv3xlSmeVDCIgaKuN2LkB9yJye30ifoBwCZyEPCSnoVa0v1DXGNpjbVOe8zc5bdI ePCS5cJS9snGgDgjDq90VJf6tHyO6YfCMrdug7Cly9YI/fnuLO0uZjjlr9XAyrPbZ1Q8YJ Ry0+uX5xT3qpiPX1bEvlEcnKutWYu4q6W76fzeq6N7vj/zKhD1O4hymW1leJ6rjWySt6e6 ckYjbH6Jbj35M3RxtXGq65Pf/m8iZCS+PI3GjqKd0I+W7kLwp8HrNjQV8INX/kcoD0AN4D LZv5TKa/BPbWh52MT/GPeGRl92V9vrih4PsXxgeNr3eaf5KHsztatER9Hhsqsg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683038553; a=rsa-sha256; cv=none; b=RnYMCuWESZqM8yWLZxetZlZeIgZtcMx5U1lC7yUP1jS+qkGSoA2+m9ZRoPXhcW6Zvako0y +VvdSHJqf5ziU/HF/rBfo+jtBydklvw74LPxGPPa0pY5I62zU1lQUZ7zyTSMO5doJCaLnC FhQjlBCWfeKxyIPoXd+ROP6O83ZcyDH3yLwqdK4A/tVjdaUuofDUHQXiGy7pWOS6gPASHT IJ+kfDl7ajK8zcCRiEmCe1F6wpE0c9X0uWmROH7nAFQuPpozZnsMA0iWhcJXRTlIOD2qmV B0y54El58vop0ebQyWj1jxMC4+C50haC1FB1fgezyv3+S9R2gzxRH8udNLjT/w== Received: from freefall.freebsd.org (pool-96-225-18-219.nwrknj.fios.verizon.net [96.225.18.219]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q9jV11lBGzFt6; Tue, 2 May 2023 14:42:33 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: Date: Tue, 2 May 2023 10:42:32 -0400 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 To: Rene Ladan Cc: "A. Wilcox" , Enji Cooper , FreeBSD-arch list References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> Content-Language: en-US From: Jung-uk Kim Organization: FreeBSD.org Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------LpSMRE608l0PizauBEQI4BdV" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------LpSMRE608l0PizauBEQI4BdV Content-Type: multipart/mixed; boundary="------------biS9aoX0W8GCV0HJtvedxL1Q"; protected-headers="v1" From: Jung-uk Kim To: Rene Ladan Cc: "A. Wilcox" , Enji Cooper , FreeBSD-arch list Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> In-Reply-To: --------------biS9aoX0W8GCV0HJtvedxL1Q Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjMuIDUuIDIuLCBSZW5lIExhZGFuIHdyb3RlOg0KPiBPbiBUdWUsIE1heSAwMiwgMjAy MyBhdCAxMjoyMDozMEFNIC0wNDAwLCBKdW5nLXVrIEtpbSB3cm90ZToNCj4+IE9uIDIzLiA1 LiAxLiwgQS4gV2lsY294IHdyb3RlOg0KPj4+IE9uIE1heSAxLCAyMDIzLCBhdCA4OjU1IFBN LCBFbmppIENvb3BlciA8eWFuZXVyYWJleWFAZ21haWwuY29tPiB3cm90ZToNCj4+Pj4gSGVs bG8sDQo+Pj4+IE9uZSBvZiB0aGUgbXVzdC1oYXZlcyBmb3IgMTQuMC1SRUxFQVNFIGlzIHRo ZSBpbnRyb2R1Y3Rpb24gb2YgT3BlblNTTA0KPj4+PiAzLjAgaW50byB0aGUgYmFzZSBzeXN0 ZW0uIFRoaXMgaXMgYSBtdXN0IGJlY2F1c2UsIGluIHNob3J0LCBPcGVuU1NMDQo+Pj4+IDEu MSBpcyBubyBsb25nZXIgc3VwcG9ydGVkIGFzIG9mIDA5LzI2LzIwMjMgWzFdLg0KPj4+Pg0K Pj4+PiBJIGFtIHByb3Bvc2luZyBPcGVuU1NMIGJlIG1hZGUgcHJpdmF0ZSBhbG9uZyB3aXRo IGFsbCBkZXBlbmRlbnQNCj4+Pj4gbGlicmFyaWVzLCBmb3IgdGhlIGZvbGxvd2luZyByZWFz b25zOg0KPj4+PiAxLiBNb3JlIHRoYW4gYSBoYW5kZnVswqBvZiBjb3JlIHBvcnRzLCBlLmcu LCBzZWN1cml0eS9weS1jcnlwdG9ncmFwaHkNCj4+Pj4gWzJdIFszXSwgc3RpbGwgZG8gbm90 IHN1cHBvcnQgT3BlblNTTCAzLjAuDQo+Pj4+IGkuwqBJZiBvdGhlciBkZXBlbmRlbnQgcG9y dHMgKGxpa2UgbGFuZy9weXRob24zOCwgZXRjKSBtb3ZlIHRvIE9wZW5TU0wNCj4+Pj4gMywg dGhlIGRpc3RyaWJ1dGVkIG1vZHVsZXMgd291bGQgYnJlYWsgb24gbG9hZCBkdWUgdG8gY2xh c2hpbmcgc3ltYm9scw0KPj4+PiBpZiB0aGUgcmlnaHQgbWl4IG9mIG1vZHVsZXMgd2VyZSBk bG9wZW7igJllZCBpbiBhIHNwZWNpZmljIG9yZGVyDQo+Pj4+IChpbXBvcnRpbmcgc3NsLCB0 aGVuIGltcG9ydGluZyBoYXptYXTigJlzIGNyeXB0byB3b3VsZCBmYWlsKS4NCj4+Pj4gaWku IFN1Y2ggcG9ydHMgc2hvdWxkIGJlIGRlcHJlY2F0ZWQvbWFya2VkIGJyb2tlbiBhcyBJ4oCZ dmUgcmVjb21tZW5kZWQNCj4+Pj4gb24gdGhlIDMuMCBleHAtcnVuIFBSIFs0XS4NCj4+Pj4g Mi7CoE9wZW5TU0wgMS4xIGFuZCAzLjAgaGF2ZSBjbGFzaGluZyBzeW1ib2xzLCB3aGljaCBt YWtlcyBsaW5raW5nIGluDQo+Pj4+IGJvdGggbGlicmFyaWVzIGF0IHJ1bnRpbWUgaW1wb3Nz aWJsZSB3aXRob3V0IHJlc29ydGluZyB0byBhIG51bWJlciBvZg0KPj4+PiBsaW5rZXIgdHJp Y2tzIGhpZGluZyB0aGUgbmFtZXNwYWNlcyB1c2luZyBzeW1ib2wgcHJlZml4aW5nIG9mIHB1 YmxpYw0KPj4+PiBzeW1ib2xzLCBldGMuDQo+Pj4+DQo+Pj4+IFRoZSBsaWJyYXJpZXMgd2hp Y2ggd291bGQgbmVlZCB0byBiZSBtYWRlIHByaXZhdGUgYXJlIGFzIGZvbGxvd3M6DQo+Pj4+ IC0ga2VyYmVyb3MNCj4+Pj4gLSBsaWJhcmNoaXZlDQo+Pj4+IC0gbGliYnNubXANCj4+Pj4g LSBsaWJmZXRjaCBbNV0NCj4+Pj4gLSBsaWJnZWxpDQo+Pj4+IC0gbGlibGRucw0KPj4+PiAt IGxpYm1wDQo+Pj4+IC0gbGlicmFkaXVzDQo+Pj4+IC0gbGlidW5ib3VuZA0KPj4+Pg0KPj4+ PiBJIHJlYWxpemUgSeKAmW0ganVtcGluZyB0byBhIHByZXNjcmliZWQgc29sdXRpb24gd2l0 aG91dCBhZGRpdGlvbmFsDQo+Pj4+IGRpc2N1c3Npb24sIGJ1dCBJ4oCZdmUgYmVlbiBkb2lu ZyBvZmZsaW5lIGFuYWx5c2lzIHJlbGF0ZWQgdG8gdXBsaWZ0aW5nDQo+Pj4+IGNvZGUgZnJv bSBPcGVuU1NMIDEueCB0byAzLnggb3ZlciB0aGUgbGFzdCBzZXZlcmFsIG1vbnRocyBhbmQg dGhpcyBpcw0KPj4+PiB0aGUgZ2VuZXJhbCBwcmVzY3JpYmVkIHNvbHV0aW9uIEnigJl2ZSBj b21lIHRvIHdoaWNoIGlzIG5lZWRlZCBmb3INCj4+Pj4gJHdvcmsuIE15IHBlcnNwZWN0aXZl IG1pZ2h0IGhhdmUgc29tZSBibGluZCBzcG90cyBhbmQgc29tZSBvZiB0aGUNCj4+Pj4gZGlz Y3Vzc2lvbiBkb25lIG92ZXIgSVJDIGFuZCBtaWdodCBuZWVkIHRvIGJlIHJlaGFzaGVkIGhl cmUgZm9yDQo+Pj4+IGhpc3RvcmljYWwgcmVmZXJlbmNlL3RvIHdpZGVuIHRoZSBkaXNjdXNz aW9uIGZvciBhbHRlcm5hdGUgc29sdXRpb25zDQo+Pj4+IHRoYXQgZG9u4oCZdCBoYXZlIHRo ZSBkZWdyZWUgb2YgdHVubmVsIHZpc2lvbiB3aGljaCB0aGUgc29sdXRpb24gSeKAmW0NCj4+ Pj4gZW1wbG95aW5nIGF0ICR3b3JrIHJlcXVpcmVzLg0KPj4+PiBJ4oCZdmUgdHJpZWQgdG8g aW5jbHVkZSBzb21lIG9mIHRoZSBwcmV2aW91c2x5IGludm9sdmVkIHBhcnRpZXMgc28gdGhl eQ0KPj4+PiBjYW4gY2hpbWUgaW4uDQo+Pj4+IFRoYW5rIHlvdSwNCj4+Pj4gLUVuamkNCj4+ Pj4NCj4+Pj4gMS4gaHR0cHM6Ly93d3cub3BlbnNzbC5vcmcvYmxvZy9ibG9nLzIwMjMvMDMv MjgvMS4xLjEtRU9MLw0KPj4+PiA8aHR0cHM6Ly93d3cub3BlbnNzbC5vcmcvYmxvZy9ibG9n LzIwMjMvMDMvMjgvMS4xLjEtRU9MLz4NCj4+Pj4gMi4gaHR0cHM6Ly9idWdzLmZyZWVic2Qu b3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNTQ4NTMNCj4+Pj4gPGh0dHBzOi8vYnVn cy5mcmVlYnNkLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/aWQ9MjU0ODUzPsKgLg0KPj4+ PiAzLiBUaGUgcmVhc29uIHdoeSBpdCBoYXNu4oCZdCBiZWVuIHVwZ3JhZGVkIGlzIGJlY2F1 c2UgbmV3ZXIgdmVyc2lvbnMNCj4+Pj4gcmVxdWlyZSBydXN0YyB0byBidWlsZCwgd2hpY2gg YXBwYXJlbnRseSBkb2VzbuKAmXQgd29yayBvbiBRRU1VIGJ1aWxkZXJzDQo+Pj4+IGR1ZSB0 byBtaXNzaW5nIGVtdWxhdGlvbiBzdXBwb3J0Og0KPj4+PiBodHRwczovL2J1Z3MuZnJlZWJz ZC5vcmcvYnVnemlsbGEvc2hvd19idWcuY2dpP2lkPTI1NDg1Mw0KPj4+PiA8aHR0cHM6Ly9i dWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxhL3Nob3dfYnVnLmNnaT9pZD0yNTQ4NTM+wqAuDQo+ Pj4+IDQuIGh0dHBzOi8vYnVncy5mcmVlYnNkLm9yZy9idWd6aWxsYS9zaG93X2J1Zy5jZ2k/ aWQ9MjU4NDEzI2MxNQ0KPj4+PiA8aHR0cHM6Ly9idWdzLmZyZWVic2Qub3JnL2J1Z3ppbGxh L3Nob3dfYnVnLmNnaT9pZD0yNTg0MTMjYzE1Pg0KPj4+PiA1LiBJZiBJIHJlbWVtYmVyIGNv cnJlY3RseSwgc29tZSBmb2xrcyBzdWdnZXN0ZWQgdGhhdCBtYWtpbmcgbGliZmV0Y2gNCj4+ Pj4gcHJpdmF0ZSB3YXNu4oCZdCByZXF1aXJlZCBzaW5jZSB0aGUgb25seSBwb3J0IHRoYXQg cmVxdWlyZWQgaXQgd2FzDQo+Pj4+IHBvcnRzLW1nbXQvcGtnLCBidXQgSSBoYXZlbuKAmXQg dmFsaWRhdGVkIHRoaXMgY2xhaW0uDQo+Pj4NCj4+Pg0KPj4+IEhpIEVuamkgKCsgYXJjaCBs aXN0KSwNCj4+Pg0KPj4+IE15IG9waW5pb24gbWF5IG5vdCBhbW91bnQgdG8gbXVjaCwgYnV0 IEnigJltIG5vdCBzdXJlIGl0IG1ha2VzIHNlbnNlIHRvDQo+Pj4gbWFrZSBpdCBwcml2YXRl IHNvbGVseSBmb3IgdGhlIHNha2Ugb2YgYWxsb3dpbmcgcG9ydHMgdG8ga2VlcCBnb2luZyB3 aXRoDQo+Pj4ga25vd24gaW5zZWN1cmUgc29mdHdhcmUuDQo+Pj4NCj4+PiBJIHRoaW5rIHBv cnRzIHNob3VsZCBiZSBsb3VkbHkgd2FybmluZywgcmlnaHQgbm93LCB0aGF0IHRoZXkgcmVx dWlyZQ0KPj4+IE9wZW5TU0wgMS54IGFuZCB0aGVyZSBzaG91bGQgYmUgd29yayB3aXRoIGJv dGggdXBzdHJlYW1zIGFuZCBlbmQgdXNlcnMNCj4+PiB0byBzZWVrIG91dCBhbmQgbWlncmF0 ZSB0byBPcGVuU1NMIDMuIMKgSSwgd2l0aCBvdGhlcnMsIGhhdmUgYWxyZWFkeQ0KPj4+IGJl Z3VuIHRoaXMgd29yayBhIHdoaWxlIGJhY2sgaW4gdGhlIExpbnV4IHdvcmxkLg0KPj4+DQo+ Pj4gSWYgdGhlIGRlc2lyZSBpcyB0byBtYWtlIHRoZXNlIGxpYnJhcmllcyBwcml2YXRlIGZv ciBmdXR1cmUNCj4+PiBpbXByb3ZlbWVudHMsIG9yIGZvciB0aGUgYWJpbGl0eSB0byBzd2Fw IGluIG90aGVyIGFub3RoZXIgY3J5cHRvL1RMUw0KPj4+IGltcGxlbWVudGF0aW9uIGFuZCBw ZXJmb3JtIGV4cGVyaW1lbnRzIGFuZCBpbm5vdmF0ZSwgdGhlbiB0aGF0IHNlZW1zDQo+Pj4g bGlrZSBpdCBjb3VsZCBiZSBhIHVzZWZ1bCB0cmFkZW9mZi4gSG93ZXZlciwgaWYgaXTigJlz IGp1c3QgdG8gYWxsb3cNCj4+PiBpbnNlY3VyZSBzb2Z0d2FyZSB0byBjb250aW51ZSB0byBi ZSB1c2VkLCBJIHRoaW5rIHRoYXQgaXMgaWxsIGFkdmlzZWQuDQo+Pj4gICDCoFRoZSBnbG9i YWwgbGFuZHNjYXBlIG9mIGluZm9ybWF0aW9uIHNlY3VyaXR5IGlzIGRpZmZlcmVudCBhbmQg SSB0aGluaw0KPj4+IGl0IHdhcnJhbnRzIGEgZGlmZmVyZW50IHJlc3BvbnNlIHRoYW4gbWF5 YmUgaXQgd291bGQgaGF2ZSBpbiB0aGUgcGFzdC4NCj4+PiAgIMKgQW5kIGl0IHNob3VsZCBh dCBsZWFzdCBiZSBhIGNvbnNpZGVyYXRpb24gdG8gaGF2ZSBhIGxvdWQgYW5kIGZvcmNlZnVs DQo+Pj4gYnJlYWsgaW4gdGhlIGludGVyZXN0IG9mIGtlZXBpbmcgZGF0YSBwcml2YXRlIGFu ZCBzZWN1cmUuDQo+Pg0KPj4gKzENCj4+DQo+PiBKdW5nLXVrIEtpbQ0KPiANCj4gKFJhbmRv bWx5IHJlcGx5aW5nKQ0KPiANCj4gUG9ydHMgdXBzdHJlYW1zIHdpbGwgcHJvYmFibHkgdGFr ZSB0aGVpciB0aW1lIChpZiBldmVyKSB0byBtaWdyYXRlIG9mZg0KPiBPcGVuU1NMIDEuWCwg YXMgd2UgaGF2ZSBzZWVuIHdpdGggUHl0aG9uIDIuNy4gSGF2aW5nIGEgcHJpdmF0ZSBsaWJy YXJ5DQo+IGZvciBPcGVuU1NMIGluIGJhc2UgbWlnaHQgYWxzbyBzaW1wbHkgdGhlIFNTTCBm cmFtZXdvcmsgaW4gcG9ydHMgKD8pDQo+IA0KPiBSZW7DqSAocGVyc29uYWwgaGF0IG9ubHkp DQoNClBsZWFzZSBub3RlIHVwZ3JhZGluZyBPcGVuU1NMIGFuZCBoYXZpbmcgcHJpdmF0ZSBs aWJyYXJ5IGFyZSBvcnRob2dvbmFsIA0KaXNzdWVzLiAgSSBkbyBub3QgZGlzYWdyZWUgd2l0 aCB0aGUgcHJpdmF0ZSBsaWJyYXJ5IGlkZWEgaWYgaXQgaXMgDQp1cGdyYWRlZCBhbmQgd2Vs bCBtYWludGFpbmVkLiAgSSBiZWxpZXZlIHN3ZWVwaW5nIHNlY3VyaXR5IA0KdnVsbmVyYWJp bGl0aWVzIHVuZGVyIHRoZSBydWcgaXMgYSByZWNpcGUgZm9yIGRpc2FzdGVyLg0KDQpKdW5n LXVrIEtpbQ0K --------------biS9aoX0W8GCV0HJtvedxL1Q-- --------------LpSMRE608l0PizauBEQI4BdV Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmRRIVgFAwAAAAAACgkQfJ+WJvzb8UaW Jgf/aJ6KMc5sfJ8ItEiEnAVVPqtcNgVivLg7sYvm8qYatRCVjtYYrmESiVMw9gHApqQaNxySsc8w m9zCSMMIGWbn5EvRYQnmkewkgUS3BimOg+1bhGBW4raaqRl+6zvMx5O1mvJ2tl51lB7R/+UKSYYg fX0m5mnNOBe8mwbJs+PxWrP7hxAOeR2/YjiGKRNyybIch247b1Tj5PmA7vP3ggp6b96Hq9bMe8C9 7VUE7K3HGWzplWb9dJUscoAANnSdzwHyRGVVu28uzkHMANvnTW+nZRfeMXsOfS0rc2YIxd+u2oqb /Cgeb4Qj2mvqCx3pnEVOvDKQvKM/xLhA8SqreuBkCw== =IuQd -----END PGP SIGNATURE----- --------------LpSMRE608l0PizauBEQI4BdV-- From nobody Tue May 2 19:02:06 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 4Q9qFb3sTQz49Hf9 for ; Tue, 2 May 2023 19:02:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9qFb22Wtz41nM; Tue, 2 May 2023 19:02:11 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4004a.ext.cloudfilter.net ([10.228.9.227]) by cmsmtp with ESMTP id te9Upn5jiLAoItvGLptavj; Tue, 02 May 2023 19:02:09 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id tvGJpPiW23fOStvGKpMCMX; Tue, 02 May 2023 19:02:09 +0000 X-Authority-Analysis: v=2.4 cv=J8G5USrS c=1 sm=1 tr=0 ts=64515e31 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=SU-xOcMpIYxLMc8R:21 a=xqWC_Br6kY4A:10 a=IkcTkHD0fZMA:10 a=P0xRbXHiH_UA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=Ntg_Zx-WAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=t6g71zzfJTaTFQDFuDgA:9 a=QEXdDO2ut3YA:10 a=hWqEdti56PxJBvPEWkoy:22 a=IjZwj45LgO3ly-622nXo:22 a=RUfouJl5KNV7104ufCm4:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id DBD8378C; Tue, 2 May 2023 12:02:06 -0700 (PDT) Received: from localhost (localhost [IPv6:::1]) by slippy.cwsent.com (Postfix) with ESMTP id B2B91283; Tue, 2 May 2023 12:02:06 -0700 (PDT) Date: Tue, 2 May 2023 12:02:06 -0700 From: Cy Schubert To: Jung-uk Kim Cc: Rene Ladan , "A. Wilcox" , Enji Cooper , FreeBSD-arch list Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Message-ID: <20230502120200.32c545e4@cschubert.com> In-Reply-To: References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> Organization: KOMQUATS X-Mailer: Claws Mail 3.19.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-CMAE-Envelope: MS4xfIF2M3pRAuILU8HnOFIJgPfj8jy/cAIm4+7vddgr9t/YK+FfZYE9CSqZH5VwHWqt7RzlF1iNGCltODt5shMDEoOfSPKitTYuUGTjHPPADskgMxU27MGL 59JxU5703EaB6iqxvBxFRL6jhFaiX3xrfdBjU3vH5pId9PifEOI4hGt5nNp+DDRVOlm8Lsv3F79Yq9ehMjXaj7g55Jtj3DD7VoYwGbdYRwa1rwQaVRrsS7Hq CnqaoP8/Si0L6HGealSla0QrVZ1Cg1sFvzikiysKSByfb1W5cfN0DFN55VljEbKQ7Yf8Id+/SQuitI6+rB5MSr53Daa5mHZMRtMdJp/61NY= X-Rspamd-Queue-Id: 4Q9qFb22Wtz41nM X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Tue, 2 May 2023 10:42:32 -0400 Jung-uk Kim wrote: > On 23. 5. 2., Rene Ladan wrote: > > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote: =20 > >> On 23. 5. 1., A. Wilcox wrote: =20 > >>> On May 1, 2023, at 8:55 PM, Enji Cooper wrote= : =20 > >>>> Hello, > >>>> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL > >>>> 3.0 into the base system. This is a must because, in short, OpenSSL > >>>> 1.1 is no longer supported as of 09/26/2023 [1]. > >>>> > >>>> I am proposing OpenSSL be made private along with all dependent > >>>> libraries, for the following reasons: > >>>> 1. More than a handful=C2=A0of core ports, e.g., security/py-cryptog= raphy > >>>> [2] [3], still do not support OpenSSL 3.0. > >>>> i.=C2=A0If other dependent ports (like lang/python38, etc) move to O= penSSL > >>>> 3, the distributed modules would break on load due to clashing symbo= ls > >>>> if the right mix of modules were dlopen=E2=80=99ed in a specific ord= er > >>>> (importing ssl, then importing hazmat=E2=80=99s crypto would fail). > >>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve re= commended > >>>> on the 3.0 exp-run PR [4]. > >>>> 2.=C2=A0OpenSSL 1.1 and 3.0 have clashing symbols, which makes linki= ng in > >>>> both libraries at runtime impossible without resorting to a number of > >>>> linker tricks hiding the namespaces using symbol prefixing of public > >>>> symbols, etc. > >>>> > >>>> The libraries which would need to be made private are as follows: > >>>> - kerberos > >>>> - libarchive > >>>> - libbsnmp > >>>> - libfetch [5] > >>>> - libgeli > >>>> - libldns > >>>> - libmp > >>>> - libradius > >>>> - libunbound > >>>> > >>>> I realize I=E2=80=99m jumping to a prescribed solution without addit= ional > >>>> discussion, but I=E2=80=99ve been doing offline analysis related to = uplifting > >>>> code from OpenSSL 1.x to 3.x over the last several months and this is > >>>> the general prescribed solution I=E2=80=99ve come to which is needed= for > >>>> $work. My perspective might have some blind spots and some of the > >>>> discussion done over IRC and might need to be rehashed here for > >>>> historical reference/to widen the discussion for alternate solutions > >>>> that don=E2=80=99t have the degree of tunnel vision which the soluti= on I=E2=80=99m > >>>> employing at $work requires. > >>>> I=E2=80=99ve tried to include some of the previously involved partie= s so they > >>>> can chime in. > >>>> Thank you, > >>>> -Enji > >>>> > >>>> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > >>>> > >>>> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > >>>> =C2=A0. > >>>> 3. The reason why it hasn=E2=80=99t been upgraded is because newer v= ersions > >>>> require rustc to build, which apparently doesn=E2=80=99t work on QEM= U builders > >>>> due to missing emulation support: > >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > >>>> =C2=A0. > >>>> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > >>>> > >>>> 5. If I remember correctly, some folks suggested that making libfetch > >>>> private wasn=E2=80=99t required since the only port that required it= was > >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. =20 > >>> > >>> > >>> Hi Enji (+ arch list), > >>> > >>> My opinion may not amount to much, but I=E2=80=99m not sure it makes = sense to > >>> make it private solely for the sake of allowing ports to keep going w= ith > >>> known insecure software. > >>> > >>> I think ports should be loudly warning, right now, that they require > >>> OpenSSL 1.x and there should be work with both upstreams and end users > >>> to seek out and migrate to OpenSSL 3. =C2=A0I, with others, have alre= ady > >>> begun this work a while back in the Linux world. > >>> > >>> If the desire is to make these libraries private for future > >>> improvements, or for the ability to swap in other another crypto/TLS > >>> implementation and perform experiments and innovate, then that seems > >>> like it could be a useful tradeoff. However, if it=E2=80=99s just to = allow > >>> insecure software to continue to be used, I think that is ill advised. > >>> =C2=A0The global landscape of information security is different and= I think > >>> it warrants a different response than maybe it would have in the past. > >>> =C2=A0And it should at least be a consideration to have a loud and = forceful > >>> break in the interest of keeping data private and secure. =20 > >> > >> +1 > >> > >> Jung-uk Kim =20 > >=20 > > (Randomly replying) > >=20 > > Ports upstreams will probably take their time (if ever) to migrate off > > OpenSSL 1.X, as we have seen with Python 2.7. Having a private library > > for OpenSSL in base might also simply the SSL framework in ports (?) > >=20 > > Ren=C3=A9 (personal hat only) =20 >=20 > Please note upgrading OpenSSL and having private library are orthogonal=20 > issues. I do not disagree with the private library idea if it is=20 > upgraded and well maintained. I believe sweeping security=20 > vulnerabilities under the rug is a recipe for disaster. Agreed. Making OpenSSL private doesn't mitigate the security risks. Making base OpenSSL private -- and subsequently krb5, as discussed many moons ago -- avoids all kinds of ports issues with the same symbols, some as functions with different arguments. It took a while to work through the various MIT/Heimdal Kerberos conflicts and other issues. The reason to make it private is to avoid difficult to resolve conflicts with packages of the same name in ports. On the ports side, some ports will require OpenSSL 1.1.1 while others will use 1.1.1 or 3.x. Package mutual exclusivity will affect users wish to install package A with OpenSSL 1.1.1 prerequisite with package B with OpenSSL 3.X prerequistite. The ports team may need different flavors of various packages. The deeper we drill into this greater the number of landmines. This might require a roadmap. >=20 > Jung-uk Kim --=20 Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=3D0 From nobody Tue May 2 19:47:33 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 4Q9rGC1drNz49LGm for ; Tue, 2 May 2023 19:47:47 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com [IPv6:2a00:1450:4864:20::531]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9rGB3Cxcz47hy for ; Tue, 2 May 2023 19:47:46 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x531.google.com with SMTP id 4fb4d7f45d1cf-50bc394919cso4864608a12.2 for ; Tue, 02 May 2023 12:47:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1683056865; x=1685648865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Pj8Eo1JFCZKYugfDkalGV6kYLvPfEqQeXOUXjX82ZGc=; b=kzSAZ36pQ4445oiPmipbEz/3nxEUshAHfLA8xN8rYS8GzHVPGYh6B+X5HKsDs5u3bg WD/hBiaikNX9UqD3kULoiMkKWRFOsDl0RmE0xcKhUKFlsYDVgmlC1ayY/vUZ3JY2lYhn FeoZlUP5A/kWY9W9MyK0xvzyf07TdI2Q7jXH59xZZD7WfWD/TPbhyBg5jyrTapezT2BX ja2rYW9q1Cf2Vzj9mr3JeSjwP+RIw8mA99XFyOzose3bvZA38LarTgDFJhLhfQs6sTxG TEmHaxNSfobo4ssrix6X9K83g+ivyV8+KNrinf1/pKTmpWAwDl9P7WI0MBwHAOuIWj2o gf/Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683056865; x=1685648865; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Pj8Eo1JFCZKYugfDkalGV6kYLvPfEqQeXOUXjX82ZGc=; b=LEB7eRYf5SE6mX8zzdj2BmOptAO3t1unakSoy11gKaUl8KZ8TXy62FfH3369qafHh9 2wbR+T9vXiWLAfXX+LBMAswYtYQQ+K3RTLnDNnRvpT/Y8jpzpXO8bP1X88prq3+YLXja iEoj0bsSqAS16thezg8+Bb36h4y21REqorD6gDtrCA6vGLq07sQkqpN1WuhnlBVT5zAT jFuAI8j7WrcundXT3Y5R2iP4nprAM5m4fWn2hIrPitTu2DCVfru5gCsxeeFL/YvGb32z 4j9ARd5gzmHj+AhPhIdeZifvZOmhoDzK+DhzoJdxTCOZwH8bjT5YEfXHRgUq20gVQ8dy sHww== X-Gm-Message-State: AC+VfDzvIbOb5XWnxXjkeOlqLnJZucd1Uyb+sxwmmLVgXUoyE+Fl7m8m QWPVfQLlgQuO/qE/lriH+pYey4ueshSAK6l0Kw/rGQ== X-Google-Smtp-Source: ACHHUZ5dIuHXzUfW0SSEGcxUvZeLWJsS8gmRMQcCQeBHU+gDxFhKsFZv0096neV09XER3ffU4c3IRdLKa3RZePuYWwc= X-Received: by 2002:a17:907:9614:b0:94e:dd3f:b650 with SMTP id gb20-20020a170907961400b0094edd3fb650mr1134566ejc.18.1683056864713; Tue, 02 May 2023 12:47:44 -0700 (PDT) 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 References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> <20230502120200.32c545e4@cschubert.com> In-Reply-To: <20230502120200.32c545e4@cschubert.com> From: Warner Losh Date: Tue, 2 May 2023 13:47:33 -0600 Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc To: Cy Schubert Cc: Jung-uk Kim , Rene Ladan , "A. Wilcox" , Enji Cooper , FreeBSD-arch list Content-Type: multipart/alternative; boundary="0000000000008ef52505fabb3621" X-Rspamd-Queue-Id: 4Q9rGB3Cxcz47hy X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --0000000000008ef52505fabb3621 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, May 2, 2023 at 1:02=E2=80=AFPM Cy Schubert wrote: > On Tue, 2 May 2023 10:42:32 -0400 > Jung-uk Kim wrote: > > > On 23. 5. 2., Rene Ladan wrote: > > > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote: > > >> On 23. 5. 1., A. Wilcox wrote: > > >>> On May 1, 2023, at 8:55 PM, Enji Cooper > wrote: > > >>>> Hello, > > >>>> One of the must-haves for 14.0-RELEASE is the introduction of > OpenSSL > > >>>> 3.0 into the base system. This is a must because, in short, OpenSS= L > > >>>> 1.1 is no longer supported as of 09/26/2023 [1]. > > >>>> > > >>>> I am proposing OpenSSL be made private along with all dependent > > >>>> libraries, for the following reasons: > > >>>> 1. More than a handful of core ports, e.g., security/py-cryptograp= hy > > >>>> [2] [3], still do not support OpenSSL 3.0. > > >>>> i. If other dependent ports (like lang/python38, etc) move to > OpenSSL > > >>>> 3, the distributed modules would break on load due to clashing > symbols > > >>>> if the right mix of modules were dlopen=E2=80=99ed in a specific o= rder > > >>>> (importing ssl, then importing hazmat=E2=80=99s crypto would fail)= . > > >>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve > recommended > > >>>> on the 3.0 exp-run PR [4]. > > >>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking = in > > >>>> both libraries at runtime impossible without resorting to a number > of > > >>>> linker tricks hiding the namespaces using symbol prefixing of publ= ic > > >>>> symbols, etc. > > >>>> > > >>>> The libraries which would need to be made private are as follows: > > >>>> - kerberos > > >>>> - libarchive > > >>>> - libbsnmp > > >>>> - libfetch [5] > > >>>> - libgeli > > >>>> - libldns > > >>>> - libmp > > >>>> - libradius > > >>>> - libunbound > > >>>> > > >>>> I realize I=E2=80=99m jumping to a prescribed solution without add= itional > > >>>> discussion, but I=E2=80=99ve been doing offline analysis related t= o > uplifting > > >>>> code from OpenSSL 1.x to 3.x over the last several months and this > is > > >>>> the general prescribed solution I=E2=80=99ve come to which is need= ed for > > >>>> $work. My perspective might have some blind spots and some of the > > >>>> discussion done over IRC and might need to be rehashed here for > > >>>> historical reference/to widen the discussion for alternate solutio= ns > > >>>> that don=E2=80=99t have the degree of tunnel vision which the solu= tion I=E2=80=99m > > >>>> employing at $work requires. > > >>>> I=E2=80=99ve tried to include some of the previously involved part= ies so > they > > >>>> can chime in. > > >>>> Thank you, > > >>>> -Enji > > >>>> > > >>>> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > > >>>> > > >>>> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > >>>> . > > >>>> 3. The reason why it hasn=E2=80=99t been upgraded is because newer= versions > > >>>> require rustc to build, which apparently doesn=E2=80=99t work on Q= EMU > builders > > >>>> due to missing emulation support: > > >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 > > >>>> . > > >>>> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > > >>>> > > >>>> 5. If I remember correctly, some folks suggested that making > libfetch > > >>>> private wasn=E2=80=99t required since the only port that required = it was > > >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. > > >>> > > >>> > > >>> Hi Enji (+ arch list), > > >>> > > >>> My opinion may not amount to much, but I=E2=80=99m not sure it make= s sense to > > >>> make it private solely for the sake of allowing ports to keep going > with > > >>> known insecure software. > > >>> > > >>> I think ports should be loudly warning, right now, that they requir= e > > >>> OpenSSL 1.x and there should be work with both upstreams and end > users > > >>> to seek out and migrate to OpenSSL 3. I, with others, have already > > >>> begun this work a while back in the Linux world. > > >>> > > >>> If the desire is to make these libraries private for future > > >>> improvements, or for the ability to swap in other another crypto/TL= S > > >>> implementation and perform experiments and innovate, then that seem= s > > >>> like it could be a useful tradeoff. However, if it=E2=80=99s just t= o allow > > >>> insecure software to continue to be used, I think that is ill > advised. > > >>> The global landscape of information security is different and I > think > > >>> it warrants a different response than maybe it would have in the > past. > > >>> And it should at least be a consideration to have a loud and > forceful > > >>> break in the interest of keeping data private and secure. > > >> > > >> +1 > > >> > > >> Jung-uk Kim > > > > > > (Randomly replying) > > > > > > Ports upstreams will probably take their time (if ever) to migrate of= f > > > OpenSSL 1.X, as we have seen with Python 2.7. Having a private librar= y > > > for OpenSSL in base might also simply the SSL framework in ports (?) > > > > > > Ren=C3=A9 (personal hat only) > > > > Please note upgrading OpenSSL and having private library are orthogonal > > issues. I do not disagree with the private library idea if it is > > upgraded and well maintained. I believe sweeping security > > vulnerabilities under the rug is a recipe for disaster. > > Agreed. Making OpenSSL private doesn't mitigate the security risks. > It limits the blast radius... But creates a new blast zone... > Making base OpenSSL private -- and subsequently krb5, as discussed many > moons ago -- avoids all kinds of ports issues with the same symbols, > some as functions with different arguments. It took a while to work > through the various MIT/Heimdal Kerberos conflicts and other issues. > The reason to make it private is to avoid difficult to resolve > conflicts with packages of the same name in ports. > Yes. We don't want to be in a situation where we can't upgrade the base openssl because of excess port entanglement... Moving to private solves that problem... for base. > On the ports side, some ports will require OpenSSL 1.1.1 while others > will use 1.1.1 or 3.x. Package mutual exclusivity will affect users > wish to install package A with OpenSSL 1.1.1 prerequisite with package > pB with OpenSSL 3.X prerequistite. The ports team may need different > flavors of various packages. > > The deeper we drill into this greater the number of landmines. This > might require a roadmap. > But does expose (I won't say create, because this issue is orthogonal to the openssl in base) an issue other projects are coping with, somehow. Warner > > > > Jung-uk Kim > > > > -- > Cheers, > Cy Schubert > FreeBSD UNIX: Web: https://FreeBSD.org > NTP: Web: https://nwtime.org > > e^(i*pi)+1=3D0 > > --0000000000008ef52505fabb3621 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Tue, May 2, 2023 at 1:02=E2=80=AFP= M Cy Schubert <Cy.Schubert@= cschubert.com> wrote:
On Tue, 2 May 2023 10:42:32 -0400
Jung-uk Kim <jkim@FreeBSD.org> wrote:

> On 23. 5. 2., Rene Ladan wrote:
> > On Tue, May 02, 2023 at 12:20:30AM -0400, Jung-uk Kim wrote:=C2= =A0
> >> On 23. 5. 1., A. Wilcox wrote:=C2=A0
> >>> On May 1, 2023, at 8:55 PM, Enji Cooper <yaneurabeya@gmail.com>= wrote:=C2=A0
> >>>> Hello,
> >>>> One of the must-haves for 14.0-RELEASE is the introdu= ction of OpenSSL
> >>>> 3.0 into the base system. This is a must because, in = short, OpenSSL
> >>>> 1.1 is no longer supported as of 09/26/2023 [1].
> >>>>
> >>>> I am proposing OpenSSL be made private along with all= dependent
> >>>> libraries, for the following reasons:
> >>>> 1. More than a handful=C2=A0of core ports, e.g., secu= rity/py-cryptography
> >>>> [2] [3], still do not support OpenSSL 3.0.
> >>>> i.=C2=A0If other dependent ports (like lang/python38,= etc) move to OpenSSL
> >>>> 3, the distributed modules would break on load due to= clashing symbols
> >>>> if the right mix of modules were dlopen=E2=80=99ed in= a specific order
> >>>> (importing ssl, then importing hazmat=E2=80=99s crypt= o would fail).
> >>>> ii. Such ports should be deprecated/marked broken as = I=E2=80=99ve recommended
> >>>> on the 3.0 exp-run PR [4].
> >>>> 2.=C2=A0OpenSSL 1.1 and 3.0 have clashing symbols, wh= ich makes linking in
> >>>> both libraries at runtime impossible without resortin= g to a number of
> >>>> linker tricks hiding the namespaces using symbol pref= ixing of public
> >>>> symbols, etc.
> >>>>
> >>>> The libraries which would need to be made private are= as follows:
> >>>> - kerberos
> >>>> - libarchive
> >>>> - libbsnmp
> >>>> - libfetch [5]
> >>>> - libgeli
> >>>> - libldns
> >>>> - libmp
> >>>> - libradius
> >>>> - libunbound
> >>>>
> >>>> I realize I=E2=80=99m jumping to a prescribed solutio= n without additional
> >>>> discussion, but I=E2=80=99ve been doing offline analy= sis related to uplifting
> >>>> code from OpenSSL 1.x to 3.x over the last several mo= nths and this is
> >>>> the general prescribed solution I=E2=80=99ve come to = which is needed for
> >>>> $work. My perspective might have some blind spots and= some of the
> >>>> discussion done over IRC and might need to be rehashe= d here for
> >>>> historical reference/to widen the discussion for alte= rnate solutions
> >>>> that don=E2=80=99t have the degree of tunnel vision w= hich the solution I=E2=80=99m
> >>>> employing at $work requires.
> >>>> I=E2=80=99ve tried to include some of the previously = involved parties so they
> >>>> can chime in.
> >>>> Thank you,
> >>>> -Enji
> >>>>
> >>>> 1. https://www.openssl.= org/blog/blog/2023/03/28/1.1.1-EOL/
> >>>> <https://www.openssl= .org/blog/blog/2023/03/28/1.1.1-EOL/>
> >>>> 2. https://bugs.free= bsd.org/bugzilla/show_bug.cgi?id=3D254853
> >>>> <https://bugs.fre= ebsd.org/bugzilla/show_bug.cgi?id=3D254853>=C2=A0.
> >>>> 3. The reason why it hasn=E2=80=99t been upgraded is = because newer versions
> >>>> require rustc to build, which apparently doesn=E2=80= =99t work on QEMU builders
> >>>> due to missing emulation support:
> >>>> https://bugs.freebsd= .org/bugzilla/show_bug.cgi?id=3D254853
> >>>> <https://bugs.fre= ebsd.org/bugzilla/show_bug.cgi?id=3D254853>=C2=A0.
> >>>> 4. https://bugs.= freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15
> >>>> <https://bugs= .freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15>
> >>>> 5. If I remember correctly, some folks suggested that= making libfetch
> >>>> private wasn=E2=80=99t required since the only port t= hat required it was
> >>>> ports-mgmt/pkg, but I haven=E2=80=99t validated this = claim.=C2=A0
> >>>
> >>>
> >>> Hi Enji (+ arch list),
> >>>
> >>> My opinion may not amount to much, but I=E2=80=99m not su= re it makes sense to
> >>> make it private solely for the sake of allowing ports to = keep going with
> >>> known insecure software.
> >>>
> >>> I think ports should be loudly warning, right now, that t= hey require
> >>> OpenSSL 1.x and there should be work with both upstreams = and end users
> >>> to seek out and migrate to OpenSSL 3.=C2=A0 I, with other= s, have already
> >>> begun this work a while back in the Linux world.
> >>>
> >>> If the desire is to make these libraries private for futu= re
> >>> improvements, or for the ability to swap in other another= crypto/TLS
> >>> implementation and perform experiments and innovate, then= that seems
> >>> like it could be a useful tradeoff. However, if it=E2=80= =99s just to allow
> >>> insecure software to continue to be used, I think that is= ill advised.
> >>>=C2=A0 =C2=A0=C2=A0The global landscape of information sec= urity is different and I think
> >>> it warrants a different response than maybe it would have= in the past.
> >>>=C2=A0 =C2=A0=C2=A0And it should at least be a considerati= on to have a loud and forceful
> >>> break in the interest of keeping data private and secure.= =C2=A0
> >>
> >> +1
> >>
> >> Jung-uk Kim=C2=A0
> >
> > (Randomly replying)
> >
> > Ports upstreams will probably take their time (if ever) to migrat= e off
> > OpenSSL 1.X, as we have seen with Python 2.7. Having a private li= brary
> > for OpenSSL in base might also simply the SSL framework in ports = (?)
> >
> > Ren=C3=A9 (personal hat only)=C2=A0
>
> Please note upgrading OpenSSL and having private library are orthogona= l
> issues.=C2=A0 I do not disagree with the private library idea if it is=
> upgraded and well maintained.=C2=A0 I believe sweeping security
> vulnerabilities under the rug is a recipe for disaster.

Agreed. Making OpenSSL private doesn't mitigate the security risks.
=

It limits the blast radius...=C2=A0 But cr= eates a new blast zone...
=C2=A0
Making base OpenSSL private -- and subsequently krb5, as discussed many
moons ago -- avoids all kinds of ports issues with the same symbols,
some as functions with different arguments. It took a while to work
through the various MIT/Heimdal Kerberos conflicts and other issues.
The reason to make it private is to avoid difficult to resolve
conflicts with packages of the same name in ports.
Yes. We don't want to be in a situation where we can't = upgrade the base
openssl because of excess port entanglement... M= oving to private
solves that problem... for base.
=C2= =A0
On the ports side, some ports will require OpenSSL 1.1.1 while others
will use 1.1.1 or 3.x. Package mutual exclusivity will affect users
wish to install package A with OpenSSL 1.1.1 prerequisite with package
p= B with OpenSSL 3.X prerequistite. The ports team may need different
flavors of various packages.

The deeper we drill into this greater the number of landmines. This
might require a roadmap.

But does expos= e (I won't say create, because this issue is orthogonal
to th= e openssl in base) an issue other projects are coping with, somehow.
<= div>
Warner
=C2=A0
>
> Jung-uk Kim



--
Cheers,
Cy Schubert <Cy.Schubert@cschubert.com>
FreeBSD UNIX:=C2=A0 <cy@FreeBSD.org>=C2=A0 =C2=A0Web:=C2=A0 https://FreeB= SD.org
NTP:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<cy@nwtime.org>=C2=A0 =C2=A0 Web:=C2=A0 https://nwt= ime.org

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 e^(i*pi)+1=3D0

--0000000000008ef52505fabb3621-- From nobody Tue May 2 20:26:24 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 4Q9s6r6GFbz49N5T for ; Tue, 2 May 2023 20:26:28 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pj1-x1031.google.com (mail-pj1-x1031.google.com [IPv6:2607:f8b0:4864:20::1031]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9s6r2hsfz4J5N; Tue, 2 May 2023 20:26:28 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pj1-x1031.google.com with SMTP id 98e67ed59e1d1-24dfc3c662eso1978195a91.3; Tue, 02 May 2023 13:26:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683059187; x=1685651187; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=wKqq7dFXfcbjI0zZc55jnjcNR+3an7JhyHpN2/4jCh4=; b=EOMZUAR9WhhQAFEQckAHJkUH/XwqjhTTWcnP+kcohzYkzj6UfDncgd5kCE2PjrR4ta QmYvxZjAZvHGYppe/+lpLvZ3qrvSV45SbHPKZxwBtUuTLWtyXj3LZN3NiOtRX8RSZ+iZ rppEiVAox0LXWfaORR741XRO0kOvn84DuzJ2XQwSmDnlpJDJcrXAja1Z6v4QnNOLz8oZ xD2nrI/qHXij32MOMr3oWfWstxUOKHzxar+rJNKSPLXFNQyQRXfsZRF5FyR6GTG1KeLX jRdWZVhrO3k8ASbUQwVw5DhjSFvC/Bl8SHFxskw4rbaXUjv08zKpQJkU3fA1KHFpTykI eLsw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683059187; x=1685651187; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=wKqq7dFXfcbjI0zZc55jnjcNR+3an7JhyHpN2/4jCh4=; b=HVMqGO1GlD29HzG5u8FenPYTCkH4KZThIzELePgKknwfZqjV1qYG5eMQv+eO2yikDM urnU7XqitXp8/7RkO0ByDZHVAEYpguO4ifWS4IeRPMvsrYFQ6C7xjUyxPLrrSlSO0l// hdXgGAgOLWMhirnoPKN3vtFHgWRIksylaULvN4YmzLF6FN7+wqshV7URuUurEqLVzeqH qcab6MCwfQ1V6TPM5hfIXbcLjb5IKq1okzLHujAfAucz/L6dvuJid0SKZgqwInq0gRgp Z5LMEepR/5l2n4iFdudQ82jJs4IdjvYKYqCynqfqj5bJiOJbMhK1qqK8wh57RSissP3J v5Pw== X-Gm-Message-State: AC+VfDzGaj6nmlVw8wFo12MyyFfogNVNY7AYvDd3Jx1TjLtQV2k2qwxw Z5zD4QvDy+o1/F2piYNEGo+FHigomxMnAw== X-Google-Smtp-Source: ACHHUZ6zRsf/FSqptm2+TiYHT8ZqD4u/OA3OEVVID7IkV0WuMy2w/6feA3H5KtlGu5OewasC9JyUDg== X-Received: by 2002:a17:90a:6043:b0:24d:cd33:e98 with SMTP id h3-20020a17090a604300b0024dcd330e98mr13970530pjm.12.1683059186823; Tue, 02 May 2023 13:26:26 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id t20-20020a17090aba9400b0023b4d4ca3a9sm8033761pjr.50.2023.05.02.13.26.25 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 May 2023 13:26:26 -0700 (PDT) From: Enji Cooper Message-Id: <23456F78-20E0-4377-927A-BBF5FA3032F2@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_9A2F367D-1ABE-4318-89EE-58B7D737D7FD"; 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 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Date: Tue, 2 May 2023 13:26:24 -0700 In-Reply-To: Cc: Cy Schubert , Jung-uk Kim , Rene Ladan , "A. Wilcox" , FreeBSD-arch list To: Warner Losh References: <89371295-EA1D-4C29-8690-C5C7BE96B178@Wilcox-Tech.com> <20230502120200.32c545e4@cschubert.com> X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Rspamd-Queue-Id: 4Q9s6r2hsfz4J5N X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9A2F367D-1ABE-4318-89EE-58B7D737D7FD Content-Type: multipart/alternative; boundary="Apple-Mail=_029E7826-EB43-408B-B735-56BAB21D8AC0" --Apple-Mail=_029E7826-EB43-408B-B735-56BAB21D8AC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 2, 2023, at 12:47 PM, Warner Losh wrote: >=20 > On Tue, May 2, 2023 at 1:02=E2=80=AFPM Cy Schubert = > wrote: > On Tue, 2 May 2023 10:42:32 -0400 > Jung-uk Kim wrote: ... > Agreed. Making OpenSSL private doesn't mitigate the security risks. (addressing this particular set of comments) Some groups with deep pockets have paid extra $$$ to keep limited 1.x = support alive for their internal use, so this is less of an issue for = them, but it=E2=80=99s definitely an issue for the OSS community. Some = groups also don=E2=80=99t have to deal with the technical and political = issues blocking package upgrades (QEMU_EMULATING), so it=E2=80=99s = easier to upgrade ports to versions that support OpenSSL 3; this = unfortunately isn=E2=80=99t true for FreeBSD given the number of = architectures and ports FreeBSD supports today. Making libraries private makes it more possible for various versions of = OpenSSL to coexist today with isolated components of a given system = ($work doesn=E2=80=99t support `pkg` on customer sites, but we use it = internally). This makes moving the codebase at $work iteratively from = OpenSSL 1.x to OpenSSL 3.x easier from a practical/risk perspective. It = doesn=E2=80=99t address the issue with shared process namespace = introduced by PAM, python, and other applications that work via = dlopen=E2=80=99ing openssl required libraries lazily, but it does solve = a class of problem. Adding FLAVORS support to ports could help address the other piece of = this puzzle in ports and would simultaneously add a great deal of = complexity to the package build matrix and dependencies as a whole = (FLAVORS would technically have to deal with base, 1.1, 3.0, 3.1, = libressl, bearssl, etc). This is something I considered and I would = definitely in support of happening _with the idea in mind that someone = with influence in the ports arena (I don=E2=80=99t have much in that = arena) would need to make these changes._ I=E2=80=99ve been impeded = enough when posting ports updates to support OpenSSL 3 in the python = arena that I=E2=80=99ve given up hope with my being able to scale fixing = all of the OpenSSL 3 related issues in ports [1]. I simply don=E2=80=99t = have the bandwidth to setup the environment and do the necessary work to = prove that what I=E2=80=99m doing won=E2=80=99t regress some form of = package building within the FreeBSD support matrix [2]. I started the discussion to highlight the fact that (as of right now) = the issues with OpenSSL 3 are less technical from a code uplift = perspective in base, and more because of technical issues introduced by = having ports rely on libraries being provided by the base system for = legacy reasons. I think I succeeded in achieving that much, but there = are some larger issues that need to be tackled first: - What should be done about ports that don=E2=80=99t support OpenSSL 3 = in the short-term and longterm? - When should the switch be flipped from OpenSSL 1.x to 3.x in base? - How will the FreeBSD project deal with OpenSSL 1.1 support on stable/ = branches with ports when upstream projects (inevitably) start pulling = OpenSSL 1.1 support from their projects [3]? Thank you, -Enji 1. FreeBSD ports updates are failure adverse instead of allowing for = failures to occur and pivoting quickly to iteratively fix problems in = ports. 2. FreeBSD doesn't have automated CI/CD for ports updates, so the = responsibility falls on the submitter=E2=80=99s shoulders to verify = their changes don=E2=80=99t break certain architectures, flavors, etc. 3. Keeping 1.1 support alive(ish) for stable/ is somewhat doable using = the DEPRECATED macros, however, it doesn=E2=80=99t resolve all potential = breaking issues when moving from 1.1 to 3.x. --Apple-Mail=_029E7826-EB43-408B-B735-56BAB21D8AC0 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 2, 2023, at 12:47 PM, Warner Losh <imp@bsdimp.com> = wrote:

On Tue, May 2, 2023 at 1:02=E2=80=AFPM Cy Schubert = <Cy.Schubert@cschubert.com> wrote:
On Tue, 2 May = 2023 10:42:32 -0400
Jung-uk Kim <jkim@FreeBSD.org> = wrote:

...

Agreed. = Making OpenSSL private doesn't mitigate the security = risks.

(addressing this particular set of = comments)

Some groups with deep = pockets have paid extra $$$ to keep limited 1.x support alive for their = internal use, so this is less of an issue for them, but it=E2=80=99s = definitely an issue for the OSS community. Some groups also don=E2=80=99t = have to deal with the technical and political issues blocking package = upgrades (QEMU_EMULATING), so it=E2=80=99s easier to upgrade ports to = versions that support OpenSSL 3; this unfortunately isn=E2=80=99t true = for FreeBSD given the number of architectures and ports FreeBSD supports = today.

Making libraries private = makes it more possible for various versions of OpenSSL to coexist today = with isolated components of a given system ($work doesn=E2=80=99t = support `pkg` on customer sites, but we use it internally). This makes = moving the codebase at $work iteratively from OpenSSL 1.x to OpenSSL 3.x = easier from a practical/risk perspective. It doesn=E2=80=99t address the = issue with shared process namespace introduced by PAM, python, and other = applications that work via dlopen=E2=80=99ing openssl required libraries = lazily, but it does solve a class of problem.

Adding FLAVORS support to ports could help address = the other piece of this puzzle in ports and would simultaneously add a = great deal of complexity to the package build matrix and dependencies as = a whole (FLAVORS would technically have to deal with base, 1.1, 3.0, = 3.1, libressl, bearssl, etc). This is something I considered and I would = definitely in support of happening _with the idea in mind that someone = with influence in the ports arena (I don=E2=80=99t have much in that = arena) would need to make these changes._ I=E2=80=99ve been impeded = enough when posting ports updates to support OpenSSL 3 in the python = arena that I=E2=80=99ve given up hope with my being able to scale fixing = all of the OpenSSL 3 related issues in ports [1]. I simply don=E2=80=99t = have the bandwidth to setup the environment and do the necessary work to = prove that what I=E2=80=99m doing won=E2=80=99t regress some form of = package building within the FreeBSD support matrix [2].

I started the discussion to highlight the fact = that (as of right now) the issues with OpenSSL 3 are less technical from = a code uplift perspective in base, and more because of technical issues = introduced by having ports rely on libraries being provided by the base = system for legacy reasons. I think I succeeded in achieving that much, = but there are some larger issues that need to be tackled = first:

- What should be done about = ports that don=E2=80=99t support OpenSSL 3 in the short-term and = longterm?
- When should the switch be flipped from OpenSSL 1.x = to 3.x in base?
- How will the FreeBSD project deal with = OpenSSL 1.1 support on stable/ branches with ports when upstream = projects (inevitably) start pulling OpenSSL 1.1 support from their = projects [3]?

Thank = you,
-Enji

1. = FreeBSD ports updates are failure adverse instead of allowing for = failures to occur and pivoting quickly to iteratively fix problems in = ports.
2. FreeBSD doesn't have = automated CI/CD for ports updates, so the responsibility falls on the = submitter=E2=80=99s shoulders to verify their changes don=E2=80=99t = break certain architectures, flavors, etc.
3. = Keeping 1.1 support alive(ish) for stable/ is somewhat doable using the = DEPRECATED macros, however, it doesn=E2=80=99t resolve all potential = breaking issues when moving from 1.1 to 3.x.
= --Apple-Mail=_029E7826-EB43-408B-B735-56BAB21D8AC0-- --Apple-Mail=_9A2F367D-1ABE-4318-89EE-58B7D737D7FD Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmRRcfAACgkQ5JFNMZeD GN6/uw/+KO8obtL7RaqTCE9qVVs6Uhg5gseQvy2Donz2iIV9Z9/JWjZPXAOmV1x8 v/vh3WUsblSPnLiNF/o++QS2b5easGpLlLq7jcbZMjJ76pCLaD8anBX0gXzTgFgE n7W6GwqCHp5FDqxoLeoGrTGVP3d+QYsNmlBEIdqYjDKUUwT1aYdUvg+tmsKzhHeO NOqg/+8aAyc1XO5jzi5ZYgl/YAgY+uu/ReaFYAKSr06X7YiE7dR2E/A8ejIcImHi zd4VTqoAL6ElxG6b/xan+GUUYLbw6Oqmw1nesrEoFGk/munzlQZrD1FqHBAgtUS/ gUIEL6iU+9jpLp6tMPHr5TRuw9oOtbUP1xqotAm4hTvWso+ZCqNJIPYUShYfr29I gyrIuH6Wtdc335vZuD1AhcF4wkBQAB+zR61+nnqNlaomahSbSeIMRXGg2A7vzadN jWPagnrHspA5Wg3AQRoOw1dIp2NUh2jPrkJpGjJV9v4iEukiqFhx2iaOGCThqtf3 G0BxEaMbxL82xTPid0WxzvNzgW+09KurIC1Wi2+p2llAtJ7pQF5dfE0rWdK7eZ5o vmHC33QzpZk3emUBCziarQMN3g6733gMn+ujjE+XwgJdOq3rAJMkt7Mcmcr3tUJD KQRKFMguGQyd1Hk1oWOwskg266pvugSnzIhQNY5VsJ6apeAILYY= =Ajkm -----END PGP SIGNATURE----- --Apple-Mail=_9A2F367D-1ABE-4318-89EE-58B7D737D7FD-- From nobody Tue May 2 21:24:05 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 4Q9tPN13tLz48BYX for ; Tue, 2 May 2023 21:24:08 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9tPM5K2zz4PJG; Tue, 2 May 2023 21:24:07 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683062647; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nEBaBeqyasa3tD3w3Szi25vmRSaZUqg4BJ2qXpzckKA=; b=eiK9cQSdAAghOZjr7m5r85jNdZv2eUZIxhrBaJg3RwM7UmwKU/NlZcHyHwU6wv28ILFi5D 25YqKeBa3I494Ve1AxCb4VqW94kqRiULVQn53WDUVfbKK6YfY6MZ/MzEnW0qUErFz9dFA1 0Qu8OeAxK+nYYTYJbkX8H30WIti/rWT+BsSv+HrNDFdNj5WUD6X09QN4yeoZ37N8SUxQJL j1jAK92MuQUX83o9TL4T2NOCwwJXNlfdSJj0xz2ffFDWIVVl2qLGWA2R+kLZWAJFdmTzuh SzjjM964RtxJEpgXU+3p2lKHdWHCfBN06x/ZXSFpGuEv6VMFRYWJzon94vS3AA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683062647; 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: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=nEBaBeqyasa3tD3w3Szi25vmRSaZUqg4BJ2qXpzckKA=; b=OgMvuOIIt65f3jS7sGQYtTMUh9Fl31USk702DoBMw8tuSW2Ep4YLezNuyYGd57FUu0JKU6 sZmCDdSm6fvS7gdeKKT9hcSXRGDCH+WUW5e3UZbtQm4NHWFLEHHWRDk5BgOMru9Nd9b6A4 oGK8lv5xw9AD60r6tsR7hHC23I1yfpTsYt6HDRuJ7+26Po14VC+SwZGfWoKhhyrNhhm+Z/ E1fX5fa9b3tAN/eglsMVymjgl/tJycoq3BEoO9cKrNnglaGUSBDINMuR/60Tl7lvUlxBYS Hv3ShCW1QbTIWcmQ/RE77UHvLXQR3FfFZqXpYOAg3SQ+EKGradBnCjUDMJ/0xA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683062647; a=rsa-sha256; cv=none; b=xXbi42DrkGWVE2jZYoifS49R/BOehHQOJdJzQEVGCt+gB6tG9HDJqj546bhNhnqEK97bC6 3sgbJuCYgDmver4f049af3YMtTL5Ib8Pn/birpb8I/6If8j4xviyS5BZZEg7YLZRrYLUTL LdVnzRmSQ8GGCQVGf5rsgkU/vkQyuvnLgAhcNWQhat2KU2Se2JM7Q3ojKEoh5POunD/Gp8 RiLF+sIRM4gD6A8f1n093mRtgimE+FrvZFiMP097tZ2zi9czfSz8EtKOCw+y1kHW/l540Q yzEycvOolERRtE5qnxKrXRczNDhZMALxUuNxcY4qnXNSiGR+nyCGQaPs1Amy1Q== Received: from [IPV6:2601:648:8680:16b0:56:ddb:b895:f1c1] (unknown [IPv6:2601:648:8680:16b0:56:ddb:b895:f1c1]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q9tPL5yPHzNjS; Tue, 2 May 2023 21:24:06 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> Date: Tue, 2 May 2023 14:24:05 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Content-Language: en-US To: Antoine Brodin , Enji Cooper Cc: FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org References: From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 5/2/23 2:59 AM, Antoine Brodin wrote: > On Tue, May 2, 2023 at 1:55 AM Enji Cooper wrote: >> >> Hello, >> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3.0 into the base system. This is a must because, in short, OpenSSL 1.1 is no longer supported as of 09/26/2023 [1]. >> >> I am proposing OpenSSL be made private along with all dependent libraries, for the following reasons: >> 1. More than a handful of core ports, e.g., security/py-cryptography [2] [3], still do not support OpenSSL 3.0. >> i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, the distributed modules would break on load due to clashing symbols if the right mix of modules were dlopen’ed in a specific order (importing ssl, then importing hazmat’s crypto would fail). >> ii. Such ports should be deprecated/marked broken as I’ve recommended on the 3.0 exp-run PR [4]. >> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in both libraries at runtime impossible without resorting to a number of linker tricks hiding the namespaces using symbol prefixing of public symbols, etc. >> >> The libraries which would need to be made private are as follows: >> - kerberos >> - libarchive >> - libbsnmp >> - libfetch [5] >> - libgeli >> - libldns >> - libmp >> - libradius >> - libunbound > > In my opinion this is a huge amount of work a few weeks before the > release. Focusing on updating OpenSSL and those core ports may be > simpler. This is my view. I think making OpenSSL private is a very huge task, and fraught with peril in ways that haven't been thought about yet (e.g. PAM) and that we can't hold up OpenSSL 3 while we wait for this. Instead, I think we need to be moving forward with OpenSSL 3 in base as-is. We will have to fix ports to work with OpenSSL 3 regardless (though this does make that pain in ports happen sooner). Moving libraries private can happen orthogonally with getting base to work with OpensSL 3. -- John Baldwin From nobody Tue May 2 21:52:22 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 4Q9v1z248Sz48D5v for ; Tue, 2 May 2023 21:52:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9v1z1bRcz3FgP; Tue, 2 May 2023 21:52:23 +0000 (UTC) (envelope-from jkim@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683064343; 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=cGjpr4K80nNDd+rijv31rZcyvUXrCLknkQ9nm661bPQ=; b=jMVizE07KOVwkK29XMyzLe5i99QZKweJP9rqqBpntE6YQz5GXCc1rN7MrvV4E4L3TAp0rk l+9Gs5kf6dw3nsj06nMoWNdP0piSSqExRGl9yMbeOrKA84rVpdXFsSegv4K17BYU4jQhgj h3pmQBZDcVWtl/a88K9RBHgiDAw4pxKbEp9/MLujW2CyTR6+NYdSj5Roqkvb4WkRSu6Zzq CRPnzY2GIvGQaEk/QI/14vsA1vsmNLA7jFekks+JwID7ctVLMOVQf5K4pEA111xKso+g3C C8c1oKU2X7bcPwfeO78nIOoHobnIdKwa9ui1pAqzcr4DfqGwthW3QqK27y0rZA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683064343; 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=cGjpr4K80nNDd+rijv31rZcyvUXrCLknkQ9nm661bPQ=; b=PFM0O522b6FcE10qIuRmq3VL0awyEZD8mbUcvfC0mZ35xKtBwCmswvZgp1peKl+CKi7vQr NBFVunuamlr7lT8Xq+MpQE+IsCqTLXFfwPZUrF7X9DFZpe2VRZkTxabxKkRuoYAfYgN0eT emtbs5a61OJObBB3aXY4fzYI1W7wurO03AxwlVpqEg4h6NBQvkFdqQRiT+OHEnlvPgVSXo eRnBOMkW71VTfGI3+CFjZ7u0ykalCYjhFhTH2ohrqk8lwRVwe1dBGKjA4U+47zplpzXJb3 zVb/PcaYRZ0uYlIpwDw1AV2kM4U407jc8zE0y2YuuyQCWBd+tTSRn/BKDBBOTw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683064343; a=rsa-sha256; cv=none; b=NId4LzMDA6MJcyf2YStErAHQbuYji6RiGPxYiAnMURiNK5tWFqiVay0cezw8zIVVGGPEud W4P7S0Z/kq3bEZsuTZnrBbJZkgGcnxepFodO7tVBjA8cDw+xkPNcfKQDyNChc1+/S4gvBz SZBKF1LT82fkl9jHackAwkVnzafC7PRnsuWZY7y1v/5kHim4C3nHIuq+8OjGtKAJf9S4Cc E1k80ZKiB3M7d8IONTEXu0ZB1NvUBgcxEgkfn19LGein26noj42JbTMk5qH+tZD5YmZxxF Tsl5J5bbrbkvqPa1UO/JLXr9q8LdFLMNMT0ylYP+F63qH++XMII9QC2YEVmGtQ== Received: from freefall.freebsd.org (pool-96-225-18-219.nwrknj.fios.verizon.net [96.225.18.219]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: jkim/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q9v1z01HnzQK8; Tue, 2 May 2023 21:52:22 +0000 (UTC) (envelope-from jkim@FreeBSD.org) Message-ID: Date: Tue, 2 May 2023 17:52:22 -0400 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Content-Language: en-US To: John Baldwin , Antoine Brodin , Enji Cooper Cc: FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> From: Jung-uk Kim Organization: FreeBSD.org In-Reply-To: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------k70SVb5V0TBH2fAO9V1sKbKa" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------k70SVb5V0TBH2fAO9V1sKbKa Content-Type: multipart/mixed; boundary="------------N8e0Mj2SqAv0Dt3WU2jUsWVF"; protected-headers="v1" From: Jung-uk Kim To: John Baldwin , Antoine Brodin , Enji Cooper Cc: FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> In-Reply-To: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> --------------N8e0Mj2SqAv0Dt3WU2jUsWVF Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjMuIDUuIDIuLCBKb2huIEJhbGR3aW4gd3JvdGU6DQo+IE9uIDUvMi8yMyAyOjU5IEFN LCBBbnRvaW5lIEJyb2RpbiB3cm90ZToNCj4+IE9uIFR1ZSwgTWF5IDIsIDIwMjMgYXQgMTo1 NeKAr0FNIEVuamkgQ29vcGVyIDx5YW5ldXJhYmV5YUBnbWFpbC5jb20+IHdyb3RlOg0KPj4+ DQo+Pj4gSGVsbG8sDQo+Pj4gT25lIG9mIHRoZSBtdXN0LWhhdmVzIGZvciAxNC4wLVJFTEVB U0UgaXMgdGhlIGludHJvZHVjdGlvbiBvZiBPcGVuU1NMIA0KPj4+IDMuMCBpbnRvIHRoZSBi YXNlIHN5c3RlbS4gVGhpcyBpcyBhIG11c3QgYmVjYXVzZSwgaW4gc2hvcnQsIE9wZW5TU0wg DQo+Pj4gMS4xIGlzIG5vIGxvbmdlciBzdXBwb3J0ZWQgYXMgb2YgMDkvMjYvMjAyMyBbMV0u DQo+Pj4NCj4+PiBJIGFtIHByb3Bvc2luZyBPcGVuU1NMIGJlIG1hZGUgcHJpdmF0ZSBhbG9u ZyB3aXRoIGFsbCBkZXBlbmRlbnQgDQo+Pj4gbGlicmFyaWVzLCBmb3IgdGhlIGZvbGxvd2lu ZyByZWFzb25zOg0KPj4+IDEuIE1vcmUgdGhhbiBhIGhhbmRmdWwgb2YgY29yZSBwb3J0cywg ZS5nLiwgc2VjdXJpdHkvcHktY3J5cHRvZ3JhcGh5IA0KPj4+IFsyXSBbM10sIHN0aWxsIGRv IG5vdCBzdXBwb3J0IE9wZW5TU0wgMy4wLg0KPj4+IGkuIElmIG90aGVyIGRlcGVuZGVudCBw b3J0cyAobGlrZSBsYW5nL3B5dGhvbjM4LCBldGMpIG1vdmUgdG8gT3BlblNTTCANCj4+PiAz LCB0aGUgZGlzdHJpYnV0ZWQgbW9kdWxlcyB3b3VsZCBicmVhayBvbiBsb2FkIGR1ZSB0byBj bGFzaGluZyANCj4+PiBzeW1ib2xzIGlmIHRoZSByaWdodCBtaXggb2YgbW9kdWxlcyB3ZXJl IGRsb3BlbuKAmWVkIGluIGEgc3BlY2lmaWMgDQo+Pj4gb3JkZXIgKGltcG9ydGluZyBzc2ws IHRoZW4gaW1wb3J0aW5nIGhhem1hdOKAmXMgY3J5cHRvIHdvdWxkIGZhaWwpLg0KPj4+IGlp LiBTdWNoIHBvcnRzIHNob3VsZCBiZSBkZXByZWNhdGVkL21hcmtlZCBicm9rZW4gYXMgSeKA mXZlIHJlY29tbWVuZGVkIA0KPj4+IG9uIHRoZSAzLjAgZXhwLXJ1biBQUiBbNF0uDQo+Pj4g Mi4gT3BlblNTTCAxLjEgYW5kIDMuMCBoYXZlIGNsYXNoaW5nIHN5bWJvbHMsIHdoaWNoIG1h a2VzIGxpbmtpbmcgaW4gDQo+Pj4gYm90aCBsaWJyYXJpZXMgYXQgcnVudGltZSBpbXBvc3Np YmxlIHdpdGhvdXQgcmVzb3J0aW5nIHRvIGEgbnVtYmVyIG9mIA0KPj4+IGxpbmtlciB0cmlj a3MgaGlkaW5nIHRoZSBuYW1lc3BhY2VzIHVzaW5nIHN5bWJvbCBwcmVmaXhpbmcgb2YgcHVi bGljIA0KPj4+IHN5bWJvbHMsIGV0Yy4NCj4+Pg0KPj4+IFRoZSBsaWJyYXJpZXMgd2hpY2gg d291bGQgbmVlZCB0byBiZSBtYWRlIHByaXZhdGUgYXJlIGFzIGZvbGxvd3M6DQo+Pj4gLSBr ZXJiZXJvcw0KPj4+IC0gbGliYXJjaGl2ZQ0KPj4+IC0gbGliYnNubXANCj4+PiAtIGxpYmZl dGNoIFs1XQ0KPj4+IC0gbGliZ2VsaQ0KPj4+IC0gbGlibGRucw0KPj4+IC0gbGlibXANCj4+ PiAtIGxpYnJhZGl1cw0KPj4+IC0gbGlidW5ib3VuZA0KPj4NCj4+IEluIG15IG9waW5pb24g dGhpcyBpcyBhIGh1Z2UgYW1vdW50IG9mIHdvcmsgYSBmZXcgd2Vla3MgYmVmb3JlIHRoZQ0K Pj4gcmVsZWFzZS7CoCBGb2N1c2luZyBvbiB1cGRhdGluZyBPcGVuU1NMIGFuZCB0aG9zZSBj b3JlIHBvcnRzIG1heSBiZQ0KPj4gc2ltcGxlci4NCj4gDQo+IFRoaXMgaXMgbXkgdmlldy7C oCBJIHRoaW5rIG1ha2luZyBPcGVuU1NMIHByaXZhdGUgaXMgYSB2ZXJ5IGh1Z2UgdGFzaywg YW5kDQo+IGZyYXVnaHQgd2l0aCBwZXJpbCBpbiB3YXlzIHRoYXQgaGF2ZW4ndCBiZWVuIHRo b3VnaHQgYWJvdXQgeWV0IChlLmcuIFBBTSkNCj4gYW5kIHRoYXQgd2UgY2FuJ3QgaG9sZCB1 cCBPcGVuU1NMIDMgd2hpbGUgd2Ugd2FpdCBmb3IgdGhpcy7CoCBJbnN0ZWFkLCBJIA0KPiB0 aGluaw0KPiB3ZSBuZWVkIHRvIGJlIG1vdmluZyBmb3J3YXJkIHdpdGggT3BlblNTTCAzIGlu IGJhc2UgYXMtaXMuwqAgV2Ugd2lsbCBoYXZlIHRvDQo+IGZpeCBwb3J0cyB0byB3b3JrIHdp dGggT3BlblNTTCAzIHJlZ2FyZGxlc3MgKHRob3VnaCB0aGlzIGRvZXMgbWFrZSB0aGF0IA0K PiBwYWluDQo+IGluIHBvcnRzIGhhcHBlbiBzb29uZXIpLsKgIE1vdmluZyBsaWJyYXJpZXMg cHJpdmF0ZSBjYW4gaGFwcGVuIG9ydGhvZ29uYWxseQ0KPiB3aXRoIGdldHRpbmcgYmFzZSB0 byB3b3JrIHdpdGggT3BlbnNTTCAzLg0KDQorMQ0KDQpKdW5nLXVrIEtpbQ0K --------------N8e0Mj2SqAv0Dt3WU2jUsWVF-- --------------k70SVb5V0TBH2fAO9V1sKbKa Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAmRRhhYFAwAAAAAACgkQfJ+WJvzb8Uas cwf6AgKOzdOOFlinxEq4I8WZBRKfLKlAqb++jdyP/YFJnf8Lag3ynHkwcuNjTlh7zzCOzMgyyK4L UJ8JxIAm2XJ8tSX0TQ/B/clGGNNefitgscR498wZ7GdmpMVQ+ebXJZunGtHyOgUT7moQ0zPTF+bN +v3z34uS9Pq4Aah8ju7gS3OvBa/hzNwX73cEgPThfhmtakYUEWNRDRanmPZ6YJa9Pb4A92dYJ1/Q ++LQboHPyz36Gxy22XqP6CRZZPMDZv3LFg8Nri21ovE2F+yz9gJyUZe6dtAkiqjK5Boh5XgNopQf U4L3dN8Xkcwx3omaP0ycLgeGK+WH8dMzYTgiArQfOg== =3RyO -----END PGP SIGNATURE----- --------------k70SVb5V0TBH2fAO9V1sKbKa-- From nobody Tue May 2 21:55:57 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 4Q9v690ZJ2z48Djb for ; Tue, 2 May 2023 21:56:01 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9v685DBBz3GNp; Tue, 2 May 2023 21:56:00 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id tmcmpnWEuLAoItxyapuI9x; Tue, 02 May 2023 21:56:00 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id txyYph43CyAOetxyZpL6kN; Tue, 02 May 2023 21:56:00 +0000 X-Authority-Analysis: v=2.4 cv=e5oV9Il/ c=1 sm=1 tr=0 ts=645186f0 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=SU-xOcMpIYxLMc8R:21 a=8nJEP1OIZ-IA:10 a=P0xRbXHiH_UA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=DWmYvZdRxjqy5wbzK3cA:9 a=wPNLvfGTeEIA:10 a=hWqEdti56PxJBvPEWkoy:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id C2A13C40; Tue, 2 May 2023 14:55:57 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id AE65339A; Tue, 2 May 2023 14:55:57 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: John Baldwin cc: Antoine Brodin , Enji Cooper , FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc In-reply-to: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> Comments: In-reply-to John Baldwin message dated "Tue, 02 May 2023 14:24:05 -0700." 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 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 02 May 2023 14:55:57 -0700 Message-Id: <20230502215557.AE65339A@slippy.cwsent.com> X-CMAE-Envelope: MS4xfGebd+RH6EJPV7btZ1uQCIc0U0b22FZiSZg2y3dn8C3+XTplOKX9LZ4h25El+YiHPfkrDmNtqicPT4zZ3U5t8tjk0CptGX2BxJOZVwA+ZicTLUjRQuDi oWR/M7hzRdBY6MMxHuAL/WwDJHRv7eftM8VAQAuBR3Xh1y3iRaYgS81Mz8ARJ5tiigfQ8WrpoljUOmpGdSiJYsm2CR0czEOW8zmNO8dOfPzEzcjkukv1KdOf B75EpsJET5NP7C2mypvcXPo+MkhKT/jXaR7FaD8KWv6dRDf8qcSOYfCeTWIXJX2L1SCjUQgHKB5RtbP2KRKhntP4N3E/WHPHKADPRLCcyeUzxIF9J86DFI24 8vekMYjrEPEsAuIL2yi82a6wVoTLcja6orefY6FHOS/j/AgJqL5wCC+9pzX5zgrM2Oun6nrmWMydMa/xzbQKSUdN5QHciQ== X-Rspamd-Queue-Id: 4Q9v685DBBz3GNp X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>, John Baldwin wri tes: > On 5/2/23 2:59 AM, Antoine Brodin wrote: > > On Tue, May 2, 2023 at 1:55 AM Enji Cooper wrote: > >> > >> Hello, > >> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3.0 > into the base system. This is a must because, in short, OpenSSL 1.1 is no lon > ger supported as of 09/26/2023 [1]. > >> > >> I am proposing OpenSSL be made private along with all dependent libraries, > for the following reasons: > >> 1. More than a handful of core ports, e.g., security/py-cryptography [2] [ > 3], still do not support OpenSSL 3.0. > >> i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, t > he distributed modules would break on load due to clashing symbols if the rig > ht mix of modules were dlopen’ed in a specific order (importing ssl, then i > mporting hazmat’s crypto would fail). > >> ii. Such ports should be deprecated/marked broken as I’ve recommended on > the 3.0 exp-run PR [4]. > >> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in both > libraries at runtime impossible without resorting to a number of linker trick > s hiding the namespaces using symbol prefixing of public symbols, etc. > >> > >> The libraries which would need to be made private are as follows: > >> - kerberos > >> - libarchive > >> - libbsnmp > >> - libfetch [5] > >> - libgeli > >> - libldns > >> - libmp > >> - libradius > >> - libunbound > > > > In my opinion this is a huge amount of work a few weeks before the > > release. Focusing on updating OpenSSL and those core ports may be > > simpler. > > This is my view. I think making OpenSSL private is a very huge task, and > fraught with peril in ways that haven't been thought about yet (e.g. PAM) > and that we can't hold up OpenSSL 3 while we wait for this. Instead, I think > we need to be moving forward with OpenSSL 3 in base as-is. We will have to > fix ports to work with OpenSSL 3 regardless (though this does make that pain > in ports happen sooner). Moving libraries private can happen orthogonally > with getting base to work with OpensSL 3. Exactly. They're idependent problems. > > -- > John Baldwin -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue May 2 21:55:57 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 4Q9xGd5DNxz48KMD for ; Tue, 2 May 2023 23:33:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9xGd2nSjz3PsY; Tue, 2 May 2023 23:33:29 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4001a.ext.cloudfilter.net ([10.228.9.142]) by cmsmtp with ESMTP id tmh7pnWQMLAoItzUupuczd; Tue, 02 May 2023 23:33:28 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id tzUspI1muHFsOtzUtpCDah; Tue, 02 May 2023 23:33:28 +0000 X-Authority-Analysis: v=2.4 cv=XZqaca15 c=1 sm=1 tr=0 ts=64519dc8 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=SU-xOcMpIYxLMc8R:21 a=8nJEP1OIZ-IA:10 a=P0xRbXHiH_UA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=DWmYvZdRxjqy5wbzK3cA:9 a=wPNLvfGTeEIA:10 a=hWqEdti56PxJBvPEWkoy:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 0214CE52; Tue, 2 May 2023 16:33:26 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id 19FA8127; Tue, 2 May 2023 14:55:57 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: John Baldwin cc: Antoine Brodin , Enji Cooper , FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc In-reply-to: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> Comments: In-reply-to John Baldwin message dated "Tue, 02 May 2023 14:24:05 -0700." 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 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 02 May 2023 14:55:57 -0700 Message-Id: <20230502231811.19FA8127@slippy.cwsent.com> X-CMAE-Envelope: MS4xfFt2aJ2htnqLKX1OehmkVso15E28lF5RFemVB1rUvxoA67AGu+jZRTfDU/zOeiTXvcy5XHSr0fwobmYAQhp/MECL824GVIsn72/y2coi1ZWWj3v7KGP9 kYlg1cQwX+s5HK8uSha8VFoigSzPO2E4dwEPwcVUdM7Pm210OUd3SfbCpHyn8g/sHAqfTbNuueYvZTnJ4y4K9aWWeHXE5ZT6XhVeTYpQwju8WRa9Chr2wy9T O0EpCoHl3uzS80KLqBMMO62e8vBKiyA4L+Qh5JpMq8WrFKhmU08RsD4AW8QBHbDsD0qAKhZCycJNtNsGo9PPFu56O/3Lx63N7ot+/pxGZMYlhv9U8bMB0+rC eyTMAtn7qU9eWRkI0LaF/SX/uNCzJDjfu2YgQqHrS3nh4sYxMHHigVLkqhx/mWmNXXLDf2ZUgM7sJz/5eCrp+zKzBCln6g== X-Rspamd-Queue-Id: 4Q9xGd2nSjz3PsY X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>, John Baldwin wri tes: > On 5/2/23 2:59 AM, Antoine Brodin wrote: > > On Tue, May 2, 2023 at 1:55 AM Enji Cooper wrote: > >> > >> Hello, > >> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3.0 > into the base system. This is a must because, in short, OpenSSL 1.1 is no lon > ger supported as of 09/26/2023 [1]. > >> > >> I am proposing OpenSSL be made private along with all dependent libraries, > for the following reasons: > >> 1. More than a handful of core ports, e.g., security/py-cryptography [2] [ > 3], still do not support OpenSSL 3.0. > >> i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, t > he distributed modules would break on load due to clashing symbols if the rig > ht mix of modules were dlopen’ed in a specific order (importing ssl, then i > mporting hazmat’s crypto would fail). > >> ii. Such ports should be deprecated/marked broken as I’ve recommended on > the 3.0 exp-run PR [4]. > >> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in both > libraries at runtime impossible without resorting to a number of linker trick > s hiding the namespaces using symbol prefixing of public symbols, etc. > >> > >> The libraries which would need to be made private are as follows: > >> - kerberos > >> - libarchive > >> - libbsnmp > >> - libfetch [5] > >> - libgeli > >> - libldns > >> - libmp > >> - libradius > >> - libunbound > > > > In my opinion this is a huge amount of work a few weeks before the > > release. Focusing on updating OpenSSL and those core ports may be > > simpler. > > This is my view. I think making OpenSSL private is a very huge task, and > fraught with peril in ways that haven't been thought about yet (e.g. PAM) > and that we can't hold up OpenSSL 3 while we wait for this. Instead, I think > we need to be moving forward with OpenSSL 3 in base as-is. We will have to > fix ports to work with OpenSSL 3 regardless (though this does make that pain > in ports happen sooner). Moving libraries private can happen orthogonally > with getting base to work with OpensSL 3. Exactly. They're idependent problems. > > -- > John Baldwin -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Tue May 2 21:55:57 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 4Q9yQD1KYSz48N4t for ; Wed, 3 May 2023 00:25:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Received: from omta001.cacentral1.a.cloudfilter.net (omta001.cacentral1.a.cloudfilter.net [3.97.99.32]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "Client", Issuer "CA" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9yQD07qnz3kXg; Wed, 3 May 2023 00:25:08 +0000 (UTC) (envelope-from cy.schubert@cschubert.com) Authentication-Results: mx1.freebsd.org; none Received: from shw-obgw-4002a.ext.cloudfilter.net ([10.228.9.250]) by cmsmtp with ESMTP id ts6KpnrgWLAoIu0Itpulyw; Wed, 03 May 2023 00:25:07 +0000 Received: from spqr.komquats.com ([70.66.148.124]) by cmsmtp with ESMTPA id u0IrphmtMyAOeu0IspLQxD; Wed, 03 May 2023 00:25:07 +0000 X-Authority-Analysis: v=2.4 cv=e5oV9Il/ c=1 sm=1 tr=0 ts=6451a9e3 a=Cwc3rblV8FOMdVN/wOAqyQ==:117 a=Cwc3rblV8FOMdVN/wOAqyQ==:17 a=SU-xOcMpIYxLMc8R:21 a=8nJEP1OIZ-IA:10 a=P0xRbXHiH_UA:10 a=6I5d2MoRAAAA:8 a=pGLkceISAAAA:8 a=YxBL1-UpAAAA:8 a=EkcXrb_YAAAA:8 a=DWmYvZdRxjqy5wbzK3cA:9 a=wPNLvfGTeEIA:10 a=hWqEdti56PxJBvPEWkoy:22 a=IjZwj45LgO3ly-622nXo:22 a=Ia-lj3WSrqcvXOmTRaiG:22 a=LK5xJRSDVpKd5WXXoEvA:22 Received: from slippy.cwsent.com (slippy [10.1.1.91]) by spqr.komquats.com (Postfix) with ESMTP id 3428D179; Tue, 2 May 2023 17:25:05 -0700 (PDT) Received: by slippy.cwsent.com (Postfix, from userid 1000) id AE65339A; Tue, 2 May 2023 14:55:57 -0700 (PDT) X-Mailer: exmh version 2.9.0 11/07/2018 with nmh-1.8+dev Reply-to: Cy Schubert From: Cy Schubert X-os: FreeBSD X-Sender: cy@cwsent.com X-URL: http://www.cschubert.com/ To: John Baldwin cc: Antoine Brodin , Enji Cooper , FreeBSD-arch list , bofh@freebsd.org, brnrd@freebsd.org, Cy Schubert , Ed Maste , vishwin@freebsd.org Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc In-reply-to: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> Comments: In-reply-to John Baldwin message dated "Tue, 02 May 2023 14:24:05 -0700." 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 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Date: Tue, 02 May 2023 14:55:57 -0700 Message-Id: <20230502215557.AE65339A@slippy.cwsent.com> X-CMAE-Envelope: MS4xfHwA9QxAJAwi40MDlQMe5brG2wV2lZgYzGKYPOx+X/bkbwY3bzzZyV4swGlvRs66OgoqAuTOyO4rnz7i1fqmanUlHfATL2FTOC4qZI4kkAQuYe/xCRoP Ilsa8sIL2cK9S8h7auzyyL1n0K9vd1c1XlasMJxHJtocCQJtOmLuezaVUkI2B2zN5Vtfk57q+xtxywEp0ufP70tQGAkCFnGkqKf7CBxBf2zoKuTzoqMk3qN+ 6afDkwqpqmO7cfa23jdGfFJ4NaLlLtgMDsxAXrMAmXjO9KD1YfNSEqhJYIWLAbkJCIZAai/sVUaeucLOa62XGjf2Fzft2jqSnWXOb9jw68KGWsfqrlc5fRTP DAgJDSRPq5O96etxDm9FPRFjzZW7ZQHqOhM5sqGwb4TwzeSzx/H+HWLNed40diZugt8fPTjWp3dMkL44B2aV8COVQRpvSA== X-Rspamd-Queue-Id: 4Q9yQD07qnz3kXg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:16509, ipnet:3.96.0.0/15, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N In message <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org>, John Baldwin wri tes: > On 5/2/23 2:59 AM, Antoine Brodin wrote: > > On Tue, May 2, 2023 at 1:55 AM Enji Cooper wrote: > >> > >> Hello, > >> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3.0 > into the base system. This is a must because, in short, OpenSSL 1.1 is no lon > ger supported as of 09/26/2023 [1]. > >> > >> I am proposing OpenSSL be made private along with all dependent libraries, > for the following reasons: > >> 1. More than a handful of core ports, e.g., security/py-cryptography [2] [ > 3], still do not support OpenSSL 3.0. > >> i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3, t > he distributed modules would break on load due to clashing symbols if the rig > ht mix of modules were dlopen’ed in a specific order (importing ssl, then i > mporting hazmat’s crypto would fail). > >> ii. Such ports should be deprecated/marked broken as I’ve recommended on > the 3.0 exp-run PR [4]. > >> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in both > libraries at runtime impossible without resorting to a number of linker trick > s hiding the namespaces using symbol prefixing of public symbols, etc. > >> > >> The libraries which would need to be made private are as follows: > >> - kerberos > >> - libarchive > >> - libbsnmp > >> - libfetch [5] > >> - libgeli > >> - libldns > >> - libmp > >> - libradius > >> - libunbound > > > > In my opinion this is a huge amount of work a few weeks before the > > release. Focusing on updating OpenSSL and those core ports may be > > simpler. > > This is my view. I think making OpenSSL private is a very huge task, and > fraught with peril in ways that haven't been thought about yet (e.g. PAM) > and that we can't hold up OpenSSL 3 while we wait for this. Instead, I think > we need to be moving forward with OpenSSL 3 in base as-is. We will have to > fix ports to work with OpenSSL 3 regardless (though this does make that pain > in ports happen sooner). Moving libraries private can happen orthogonally > with getting base to work with OpensSL 3. Exactly. They're idependent problems. > > -- > John Baldwin -- Cheers, Cy Schubert FreeBSD UNIX: Web: https://FreeBSD.org NTP: Web: https://nwtime.org e^(i*pi)+1=0 From nobody Wed May 3 01:14:43 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 4Q9zWg1Gcsz48gbw for ; Wed, 3 May 2023 01:14:55 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Q9zWg0mDBz42q5; Wed, 3 May 2023 01:14:55 +0000 (UTC) (envelope-from bofh@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683076495; 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=fIjxs3/ivJXqGM/5QxaWhC60V9qUZRYZ6yW0qWQNcBk=; b=vRgAYBQTpBdtOMeyHSvfnTwVyWu4Rxyuc/m7sNi9Kcgs5TN3lNulqknsZz7RDnEqjUiDP2 UJ0PO86GXjbGaYCl3B02nmvbniA8yItYsK00Gao5iY865tV9sKro7pUwaxrngb7YDH24li Ou66ATk8ddZhhvK4OeVWvlS9c/OhhXInjM4UDWdNqziYYMETjUcq++JSc1e14XnAxGevyd II6oAYd1InLlNzzoxkgJK3m8ZyRdAQHPcISYHp3sRaYQbco8v69VrUAx8uFEEXnyqYaPHP tSmepaDNNgn8gNDYAtRBKr9It7JTkca9IZ4XkPooO+OS+f/uteRNg72T0ACcsg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683076495; 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=fIjxs3/ivJXqGM/5QxaWhC60V9qUZRYZ6yW0qWQNcBk=; b=fD+RP+haV1xF25y7Wiuk45wJ66UaRe+5g8Vg6giezBeNXpYs3wLHH1z3By/rYuWPiRyHLx Vofd6w7kYeWS1yyUGP12RRlAVwjXnsUoKIkvibfyzU6Jw577hdqF4s9x/ax/sspU64lnsz LupQu3zewvUlX0s3a037lOtBIAz94QGmTBybt4Rc7O/ybBpu4/droxK3NcWcoz8PoFpMFW 8/3IOlb/XuEkGqGD+K5yJPO5/v8KyObGCCbzNiNgMbryoCIvUV0nbgdDE7Hsw9LtAUrAAS P8q7XaLvE3hOAdO4WImarFHhKZhKHAXD4g4chiWPoZnPwydNzerVJ7qo3/rvxg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683076495; a=rsa-sha256; cv=none; b=PBZ2bbJsO8l+vNdKJrpdziryOtkl1IYrBomlnJUL1y5Ot4HmMDboi+iA8Hu6ajxsz4gh0A UTh/qgMjq0t/Q4wCksv15ZQxGIn8K8ioBwzvRGqdOWpdsCESZPiP7GzL5gAldlVJwh43MI 49PIfTTZ8zSYnPasZ5S+bvOAp7g9u77Df9djodTcXMtvGD0rkWIbA75DgjFoigCV4Gzgb3 12qZJeJ0E0ZpuCyBmzVFVPeMCbTbY3p6WX+E7YRD2t8Atc+d/yTHwnZKk+Tx46j3dVznrc tWwUGFykRj5YgSmPVugVvwHxwGKpr2TV6lpXBJhU8X54hjkqyt0/Uc/i98uoiw== Received: from mx.bofh.network (mx.bofh.network [IPv6:2a01:4f8:261:25de::227]) (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 "mx.bofh.network", Issuer "R3" (verified OK)) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4Q9zWf2293zTX2; Wed, 3 May 2023 01:14:54 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtpclient.apple ( [80.113.232.31]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id 9816bec5 (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Wed, 3 May 2023 01:14:48 +0000 (UTC) Content-Type: multipart/signed; boundary="Apple-Mail=_C81EE0DB-2FC8-45AD-815E-862B37AC12EB"; protocol="application/pgp-signature"; micalg=pgp-sha512 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 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc From: Moin Rahman In-Reply-To: Date: Wed, 3 May 2023 03:14:43 +0200 Cc: FreeBSD-arch list , Bernard Spil , Cy Schubert , Ed Maste , vishwin@freebsd.org Message-Id: References: To: Enji Cooper X-Mailer: Apple Mail (2.3696.120.41.1.3) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_C81EE0DB-2FC8-45AD-815E-862B37AC12EB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 2, 2023, at 3:55 AM, Enji Cooper wrote: >=20 > Hello, > One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL 3.0 into the base system. This is a must because, in short, = OpenSSL 1.1 is no longer supported as of 09/26/2023 [1]. >=20 > I am proposing OpenSSL be made private along with all dependent = libraries, for the following reasons: > 1. More than a handful of core ports, e.g., = security/py-cryptography [2] [3], still do not support OpenSSL 3.0. > i. If other dependent ports (like lang/python38, etc) = move to OpenSSL 3, the distributed modules would break on load due to = clashing symbols if the right mix of modules were dlopen=E2=80=99ed in a = specific order (importing ssl, then importing hazmat=E2=80=99s crypto = would fail). > ii. Such ports should be deprecated/marked broken as = I=E2=80=99ve recommended on the 3.0 exp-run PR [4]. > 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes = linking in both libraries at runtime impossible without resorting to a = number of linker tricks hiding the namespaces using symbol prefixing of = public symbols, etc. >=20 > The libraries which would need to be made private are as = follows: > - kerberos > - libarchive > - libbsnmp > - libfetch [5] > - libgeli > - libldns > - libmp > - libradius > - libunbound >=20 > I realize I=E2=80=99m jumping to a prescribed solution without = additional discussion, but I=E2=80=99ve been doing offline analysis = related to uplifting code from OpenSSL 1.x to 3.x over the last several = months and this is the general prescribed solution I=E2=80=99ve come to = which is needed for $work. My perspective might have some blind spots = and some of the discussion done over IRC and might need to be rehashed = here for historical reference/to widen the discussion for alternate = solutions that don=E2=80=99t have the degree of tunnel vision which the = solution I=E2=80=99m employing at $work requires. > I=E2=80=99ve tried to include some of the previously involved = parties so they can chime in. > Thank you, > -Enji >=20 > 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ > 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions require rustc to build, which apparently doesn=E2=80=99t work = on QEMU builders due to missing emulation support: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . > 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 > 5. If I remember correctly, some folks suggested that making libfetch = private wasn=E2=80=99t required since the only port that required it was = ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. Hi Enji, I appreciate your work creating the bugs but please hold on a moment = before you create the bugs. It will slow me down. While you were wasting your time creating the ticket for nrpe3 I have = already updated the port to 4.1.0 to unbreak. So until I have the final = list which you will have by end of this week please do not create = tickets. And I have not exactly described the process too what I was doing. The = list you are getting in my poudriere might have two possible failure = reason. OpenSSL 3 or LLVM15; and some might be fixed with little = intervention and testing. And as it's not possible to ask poudriere not = to try BROKEN ports so I have marked some port as blacklisted which are = unfixable or broken for other reasons. If you really would like to = create tickets and chase upstream please do: find /usr/local/poudriere/ports/default -name Makefile -type f -d 3 = -exec grep -E '(BROKEN_SSL\=3D|IGNORE_SSL\=3D).*openssl3' {} \+ Thanks for your cooperation. --Apple-Mail=_C81EE0DB-2FC8-45AD-815E-862B37AC12EB Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEETfdREoUGjQZKBS+fvbm1phfAvJEFAmRRtYNfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRE Rjc1MTEyODUwNjhEMDY0QTA1MkY5RkJEQjlCNUE2MTdDMEJDOTEACgkQvbm1phfA vJEi3w//falgi9CZwY0MGWJbMBVDIueD1sI5FNtd4oP5f1PaPloUDjmxer9X53Os be3/nB/UH2v6Ns8mSMXVCPt70PtrN5eTzuU+eALdhiVVDEbfW3pdoqJll60QuuTe cqLYeShqrLAuB8ZbWFnCTLGumCAakO2bvXFOZgzxcHY3ZeK8OyFqF5F8n9zJLCTU 1XjwrpJ0V1AgGwNEsGJDXM96PATBZQoMgvv/Z3itMB5oLV0VjfGfi5gq3XRB6NtD kCmnuEo6wA7ZsO4NRJzofKc9CpRe6WaArbSjnmjl3bBP2GVhKtStPfvePhbDBrz3 5z566YJoSJcDFHglD9FocmOxrraKShu+p6wuA3yVw7BuRR8kWhXyBjpoYp0IXW2x SXQ5dU1Brr2vn85217QUCPy5SNxyWXiSXLjEzf15a8fPhmXeW+8h+dZSuJJA1Op4 i3027suWVCxOHaq50CR2IsRfNSUquYGmqtpm7rIT6prBA+BPE4Ji9zynFLTnCDfU VZguEfMhOC+M4+OTrXJvnH6hVIEM39fyYjmNlL8SnQ4VAk/4eP3y17sIYu9n7PyA EHPuJvzdvGcQ1QpNorP99sR5S3Aejte0Qg++P7A3hD0u+Uf+d1PIPMmhtC2vw8tm ZuMFv/W9CFFQZ+IyMAJ9ViWUVzWvEGxWMu5wiWu7CP6OkFD37XM= =p5dC -----END PGP SIGNATURE----- --Apple-Mail=_C81EE0DB-2FC8-45AD-815E-862B37AC12EB-- From nobody Wed May 3 06:02:33 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 4QB5vn2Y3Pz48xmr for ; Wed, 3 May 2023 06:02:45 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QB5vm0RYcz4NM0; Wed, 3 May 2023 06:02:44 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b=jsjRCUBd; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net; dmarc=pass (policy=reject) header.from=delphij.net Received: from odin.corp.delphij.net (unknown [IPv6:2001:470:48ca:5:51a3:cfbd:9967:8fb6]) by anubis.delphij.net (Postfix) with ESMTPSA id 254E359138; Tue, 2 May 2023 23:02:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1683093757; x=1683108157; bh=uOnoO2CdJbxxzt2I7XFawo3iRdUEdvkhIRPV5OMz0k0=; h=Date:Reply-To:To:Cc:References:From:Subject:In-Reply-To; b=jsjRCUBd9hlaWEBtMKhn5l9Fvmnjfd/nWYMmmO1WNpLkem58BEJC0TUpY75qMfitL Jo8ktIwroV0649YBZs4ReCTo5l0Z5i8IqfNrHklfDUVMsKd7QAcTiYtIUublBAJ+sB iT0vmkJ/voyhBzi1eP4gQ9EH5axyZZo7SSi3VV2Xh+g7ISfWXTxZMBW/nGU/8t0YKa 5SFY4cYREBW6vXz8JKsZzjghtObyDLMr0e5EATn/A9Rkx5G5p0pjB8z9acH0SfaaGq tM4cvCbh6qkJQqLrL6UuFB+RGcFbq3t5s3lpVMAptklT+xYlyGGKpJRrLRX9XSpdOj OWDq0+q5sZBiA== Message-ID: <21eaeda3-897c-fdc2-980e-212642ac6f26@delphij.net> Date: Tue, 2 May 2023 23:02:33 -0700 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 User-Agent: Thunderbird Reply-To: d@delphij.net To: Baptiste Daroussin , Ed Maste Cc: Konstantin Belousov , freebsd-arch References: Content-Language: en-US From: Xin Li Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------59kGMQD8mFB1cczH8wDzL7zy" X-Spamd-Result: default: False [-4.15 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; NEURAL_HAM_SHORT(-0.16)[-0.156]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; HAS_REPLYTO(0.00)[d@delphij.net]; TO_MATCH_ENVRCPT_SOME(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; BLOCKLISTDE_FAIL(0.00)[2001:470:48ca:5:51a3:cfbd:9967:8fb6:server fail,64.62.153.212:server fail]; FREEFALL_USER(0.00)[delphij]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_ALL(0.00)[]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; FROM_EQ_ENVFROM(0.00)[]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QB5vm0RYcz4NM0 X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------59kGMQD8mFB1cczH8wDzL7zy Content-Type: multipart/mixed; boundary="------------R0WFCOSb1BM3ndT0Q0JcXj52"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Baptiste Daroussin , Ed Maste Cc: Konstantin Belousov , freebsd-arch Message-ID: <21eaeda3-897c-fdc2-980e-212642ac6f26@delphij.net> Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: In-Reply-To: --------------R0WFCOSb1BM3ndT0Q0JcXj52 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0wNC0yNSAyOjMwIEFNLCBCYXB0aXN0ZSBEYXJvdXNzaW4gd3JvdGU6PiBPciBl dmVuIGFuIGludGVybmFsbGliIA0KY29uc2lkZXJpbmcgdGhlcmUgd2lsbCBiZSBkbyBjb25z dW1lciBsZWZ0IGJ1dCBmZXRjaCgxKQ0KVGhlcmUgaXMgYW4gT3BlbkxEQVAgYnVpbGQgdGlt ZSBvcHRpb24gdGhhdCBpcyB1c2luZyBmZXRjaCgzKSBBUEk7IGl0J3MgDQpub3QgZW5hYmxl ZCBieSBkZWZhdWx0Lg0KDQpJIGJlbGlldmUgbmV0L21wZDUgYWxzbyB1c2VzIGxpYmZldGNo Lg0KDQpDaGVlcnMsDQo= --------------R0WFCOSb1BM3ndT0Q0JcXj52-- --------------59kGMQD8mFB1cczH8wDzL7zy Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEceNg5NEMZIki80nQQHl/fJX0g08FAmRR+PkFAwAAAAAACgkQQHl/fJX0g08/ OBAAih3LL422lgvSFYdHapyzXqxckTnA3p1su0C488nhprqLFOLjz72NR6CRdW5xw+Qtd8ncvMhP W26AA4FcfkQI51BoV3dq2xV3yHedAdHzyWBzV7ZM4OtKVAjqJ1lFoPCK50aQKKfytHvfZ2Vuo3UY tH+wqtc9M2U0nIvaCmuRe01a2gPYncREedS/VCIkeE/Gs4dXTIlU/FpUjrIWDnk2aNAO1cqdJKp1 zptFIedYb7+Gn67VyVttpQW/cvLhFlMRSRZ3ww/KU8Kw95YKmP9UCMTm4OkgrioqWrYfnFjVisg8 OB0/J0DPB86hrsGB0Gii0GOkPhngyR/meuKRq8gj3Orau2jIrxB6TLmnWk6VDCEvI2ZAncnItssX 571pEPtWTeP4RXx477BTXeCtg9+tvvbDTbQaZ+7gRPgBH1HGLPr2Ya+k+i0Yf/m+UipqOgr8H+Xh y+r9Dwdfxw8e61LuiaXjhD8ow+AelL53ERGt5UgaakLKA4+ZpXUJsXCknyAIkYFYQrVM4lCqz3WG vcUaZEFnD7vyVCwicBgIGFslXBVVR7Ymh9w7FUg5O18LaQs16Bhm4DfR/S5B0dS/0A3YuhDF6mw8 4GfWTvxeAAWkAG/dQOPhIuuA7ux3ej7xjMt1wiatV4Lm9hoNE2fIy0+nKf2iBqrnBpoMumFP1LoN MTo= =PJSl -----END PGP SIGNATURE----- --------------59kGMQD8mFB1cczH8wDzL7zy-- From nobody Wed May 3 06:22:18 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 4QB6LQ5KfKz48y64 for ; Wed, 3 May 2023 06:22:22 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [64.62.153.212]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QB6LP50dxz4PRx; Wed, 3 May 2023 06:22:21 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b=igxgexhn; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 64.62.153.212 as permitted sender) smtp.mailfrom=delphij@delphij.net; dmarc=pass (policy=reject) header.from=delphij.net Received: from odin.corp.delphij.net (unknown [IPv6:2001:470:48ca:5:51a3:cfbd:9967:8fb6]) by anubis.delphij.net (Postfix) with ESMTPSA id 12539591A6; Tue, 2 May 2023 23:22:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1683094941; x=1683109341; bh=FEtjihpwrVANoxcvDfvThPnu06xOyS+Dy86g1U25qWU=; h=Date:Reply-To:To:Cc:References:From:Subject:In-Reply-To; b=igxgexhn2hHaV+XTy3DY9oLLwIsAZyAcz7I4BNWX+3iZLrJvhwkj58JCQoxkT0ckp 8Go8E3Fc/3i3bizOsOS/y/CBrIcrGP0bDwcnZy9dlLtFgPu5omcKPbqxn7YBn76yPb jUG3n/WFZhTfxtXc30mjDX7mfNBEik76o+8Cyt1sY9UKa6yGQEdPTg3slvA4qBkzwv n05U75mocRwyts7EPGyIe6P3wcmeASXnPYyhVK12x+Eoc5gd6idSAC979hSZFjZ5ZK tDdwd6BMT6cCwzGpkTja9Nv3iilwbnCEz3jbxF1pNqgzqkBX35BDYGogaCsMjNXoCp VUk6Ckn9gq97w== Message-ID: <06ec1de8-0530-dd94-ac77-bf5a63556e2e@delphij.net> Date: Tue, 2 May 2023 23:22:18 -0700 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 User-Agent: Thunderbird Reply-To: d@delphij.net Content-Language: en-US To: Dimitry Andric , Warner Losh Cc: Charlie Li , Ed Maste , Joerg Pulz , freebsd-arch References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> From: Xin Li Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------sPJN059yP7tzc0bhTMm0kNC8" X-Spamd-Result: default: False [-4.72 / 15.00]; SIGNED_PGP(-2.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-0.73)[-0.726]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FREEFALL_USER(0.00)[delphij]; FROM_HAS_DN(0.00)[]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; BLOCKLISTDE_FAIL(0.00)[64.62.153.212:server fail,2001:470:48ca:5:51a3:cfbd:9967:8fb6:server fail]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; HAS_REPLYTO(0.00)[d@delphij.net]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_FIVE(0.00)[6]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; TO_DN_ALL(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; ASN(0.00)[asn:6939, ipnet:64.62.128.0/18, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QB6LP50dxz4PRx X-Spamd-Bar: ---- X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------sPJN059yP7tzc0bhTMm0kNC8 Content-Type: multipart/mixed; boundary="------------LPazrSSoYBjlW4zdqucd10yO"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Dimitry Andric , Warner Losh Cc: Charlie Li , Ed Maste , Joerg Pulz , freebsd-arch Message-ID: <06ec1de8-0530-dd94-ac77-bf5a63556e2e@delphij.net> Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: <8e00be00-e327-64d2-0018-7525a1ba6f2e@freebsd.org> In-Reply-To: --------------LPazrSSoYBjlW4zdqucd10yO Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0wNC0yNCA3OjQ5IEFNLCBEaW1pdHJ5IEFuZHJpYyB3cm90ZToNCj4gT24gMjQg QXByIDIwMjMsIGF0IDE2OjM5LCBXYXJuZXIgTG9zaCA8aW1wQGJzZGltcC5jb20+IHdyb3Rl Og0KPj4NCj4+IE9uIE1vbiwgQXByIDI0LCAyMDIzLCA4OjMzIEFNIENoYXJsaWUgTGkgPHZp c2h3aW5AZnJlZWJzZC5vcmc+IHdyb3RlOg0KPj4gRWQgTWFzdGUgd3JvdGU6DQo+Pj4gVGhl IHByb2JsZW0gaXMgdGhhdCB3ZSBoYXZlIGNvbmZsaWN0aW5nIGNvbnN0cmFpbnRzOiBPcGVu U1NMIDEuMS4xIGlzDQo+Pj4gRU9MIHNob3J0bHkgYWZ0ZXIgMTQuMCByZWxlYXNlcywgYW5k IHRoZXJlIGFyZSBwb3J0cyB0aGF0IGRvIG5vdCB5ZXQNCj4+PiBidWlsZCBhZ2FpbnN0IE9w ZW5TU0wgMy4gSSBhbSBub3Qgc3VyZSBob3cgbXVjaCB3aWxsIGJlIGJyb2tlbiBpZiB3ZQ0K Pj4+IHVwZGF0ZSB0aGUgYmFzZSBzeXN0ZW0gdG8gT3BlblNTTCAzIGJ1dCBsZWF2ZSB0aGUg cHJpdmF0ZWxpYiBhc2lkZQ0KPj4+IChpLmUuLCBoYXZlIHRoZSBiYXNlIHN5c3RlbSBwcm92 aWRlIE9wZW5TU0wgMyB0byBwb3J0cykuDQo+Pj4NCj4+IE9wZW5TU0wgMyBpcyBhIG1ham9y LCBldmVuIGxhcmdlciB0aGFuIDEuMSwgQVBJL0FCSSBjaGFuZ2UuIFF1aXRlIGEgYml0DQo+ PiBvZiBzdHVmZiB3aWxsIGJlIGJyb2tlbiB0b2RheS4gVGhlIGVmZm9ydCBoZXJlIGhhcyB0 byBpbmNsdWRlIHdvcmtpbmcNCj4+IHdpdGggYXMgbWFueSBwb3J0IHVwc3RyZWFtcyBhcyBw b3NzaWJsZSB0byBmb3JjZSB0aGUgaXNzdWUsIGFzIHRoZXkgbWF5DQo+PiBub3QgaG9sZCBP cGVuU1NMIDMgY29tcGF0aWJpbGl0eSB0byBiZSBhbiBpbW1lZGlhdGUgcHJpb3JpdHk7IHBh dGNoaW5nDQo+PiBwb3J0cyBvbiBhIGxhcmdlIHNjYWxlIGxpa2UgdGhpcyBpcyBub3Qgc3Vz dGFpbmFibGUuDQo+Pg0KPj4gU28gd2h5IGNhbid0IHBvcnRzIGxpa2UgdGhpcyB1c2UgMS4x IGFzIGEgcG9ydCByYXRoZXIgdGhhbiBmcm9tIGJhc2U/DQo+IA0KPiBUcm91YmxlIHN0YXJ0 cyB3aGVuIHlvdSBhdHRlbXB0IHRvIG1peCBvcGVuc3NsIDEuMSBhbmQgMy4wIGxpYnJhcmll cw0KPiAoYm90aCBkeW5hbWljIGFuZCBzdGF0aWMhKSBpbiBkZXBlbmRlbnQgcG9ydHMsIGJl Y2F1c2Ugc3ltYm9sIG5hbWVzIHdpbGwNCj4gY29sbGlkZS4NCj4gDQo+IFRoaXMgaXMgbm90 IGFuIGVhc2lseSBzb2x2YWJsZSBwcm9ibGVtLCBhcGFydCBmcm9tIHRoZSBmYWN0IHRoYXQg YW4NCj4gb3BlbnNzbCAxLjEgcG9ydCB3b3VsZCBoYXZlIHRoZSBzYW1lIGJhc2ljIGlzc3Vl IHRoYXQgb3BlbnNzbCAxLjEgaW4gdGhlDQo+IGJhc2Ugc3lzdGVtIGhhczogaXQgd2lsbCBu byBsb25nZXIgYmUgc3VwcG9ydGVkIChhdCBsZWFzdCB3aXRob3V0IHBheWluZw0KPiB1cCkg YWZ0ZXIgJENVVE9GRl9EQVRFLg0KDQoNCihEaXNjbGFpbWVyOiBJJ20gbm90IGEgYmlnIGZh biBvZiBtYWtpbmcgT3BlblNTTCBhIHByaXZhdGUgbGlicmFyeSwgYnV0IA0KSSB0aGluayBp dCBzaG91bGQgYmUgcG9zc2libGUgdG8gZG8gaXQgaWYgd2Ugd2FudCB0by4uLikNCg0KSSB0 aGluayB3ZSBjcmVhdGUgYSBzZXBhcmF0ZSBoZWFkZXIgZmlsZSAoZS5nLiANCnByaXZhdGVf b3BlbnNzbF9uYW1lc3BhY2UuYykgd2hpY2ggbWVjaGFuaWNhbGx5ICNkZWZpbmUncyBhbGwg ZXhwb3J0ZWQgDQpzeW1ib2xzIHRvIHNvbWV0aGluZyB1bmlxdWUgYW5kIGRvIG5vdCBjb2xs aWRlIHdpdGggT3BlblNTTCwgbGlrZSB3aGF0J3MgDQpkb25lIGZvciBsaWJtZC4gIChhbmQg dGhlIGhlYWRlciBjYW4gYmUgZ2VuZXJhdGVkIGJ5IHBhcnNpbmcgdGhlIG5tIC1EIA0Kb3V0 cHV0IG9mIHRoZSBPcGVuU1NMIGxpYnJhcmllcykNCg0KQ2hlZXJzLA0KDQo= --------------LPazrSSoYBjlW4zdqucd10yO-- --------------sPJN059yP7tzc0bhTMm0kNC8 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEceNg5NEMZIki80nQQHl/fJX0g08FAmRR/ZoFAwAAAAAACgkQQHl/fJX0g09j XA//XpUlYnsBPX0QS2eTN8ITBJI+qd5agh3HyduJFajbWVG6Uq5zdX/06afrGVMOdxtEbqvO+gIC RN0poS2EI8hGrKTMbgyn/73zWycdXmFQSHqGoORlBffrWAJgW/2O8+EI4f1jNOIjRIlj3u/+YmXc 8zLe5jZnmtwBB2Cc3FyekieObJaabBMasFx7kwdE3QHcBdx1w1t0voqOd8U+jiAm5X54LqRQJYJt MOGzh/5K67gTibzBazCM+HGSw0FSLLawBf4Eb5xqRQEaTfMzgn+slz41hg2OGL+OmDydcFgKbhaM m7AHN2DDMd4oK4kt8myHMlWvXICJzDrR8yUEdoWV/zsOchsUVFnwDAXTOdAN/AlBHgsks8WSdLVM NHLXqunnEZMf1LDV5KxjuoOxvctkwCL7vynmWBxUobPofcxFZCw8/Z7J8kprHWga4N/gblx0mCm7 BvungBgAuWiYUCZ+py5RmSUAORQKID+owCmlqrDE6cfvFnAieUCt6E/BaIMqqLQnsarN5wHnosm/ ooOXMRQFBmWlYPrCOAKg3rLR+tk6l/vqOXRyrQ8QY+1DjcqG1aqiOo/YhJyL7sLzH+yk5SNv2S9f 7P+kxEmtuW9rPCXMDfsgCgnEDtOQCNpDn1JoFsyMHHOnXV1W02OZQYY5THuek7qATi0FNkExOl96 jVM= =Gn7i -----END PGP SIGNATURE----- --------------sPJN059yP7tzc0bhTMm0kNC8-- From nobody Wed May 3 06:35:58 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 4QB6fJ61S0z48ywq for ; Wed, 3 May 2023 06:36:08 +0000 (UTC) (envelope-from delphij@delphij.net) Received: from anubis.delphij.net (anubis.delphij.net [IPv6:2001:470:1:117::25]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "anubis.delphij.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QB6fH2cQhz4Qsm; Wed, 3 May 2023 06:36:07 +0000 (UTC) (envelope-from delphij@delphij.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=delphij.net header.s=m7e2 header.b=E8ebBcE6; spf=pass (mx1.freebsd.org: domain of delphij@delphij.net designates 2001:470:1:117::25 as permitted sender) smtp.mailfrom=delphij@delphij.net; dmarc=pass (policy=reject) header.from=delphij.net Received: from odin.corp.delphij.net (unknown [IPv6:2001:470:48ca:5:51a3:cfbd:9967:8fb6]) by anubis.delphij.net (Postfix) with ESMTPSA id 9A3FD5907C; Tue, 2 May 2023 23:35:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=delphij.net; s=m7e2; t=1683095760; x=1683110160; bh=hsA4Yhjkt6/g3Uxl0HLUmYpfYr8gWORTOactkZQx3Hw=; h=Date:Reply-To:To:References:From:Subject:In-Reply-To; b=E8ebBcE6dkF5194LVjIbINtPbCY+EqfDnK9yD4aYSTpzTJKumUOAp45ise95vupxP bZKOd6pmyT+gPl4RmgWIPOsf56uyix1qmwt+wYMaEH22CXHwqBqcwzBiJmVvS5v/ty j7aLDdaXTCwCCD+dW+mZO6sE0utTlFygq8MyA2v+2k6Z71hmD5GsX2bt0AcCHoPCNe OH565dJLks4qVZ4laqbILsAHM1Q44yMVnsT4tUrYUqLM5qJDOFmUgzkPnutOry1K4s pF8UT/tfsVnWSAHNqE1CCdsp5ltR153jJkakpkjoSHiZoPH54CpZ3nqIsTRycExE/y GfnrrVkBXfhcw== Message-ID: Date: Tue, 2 May 2023 23:35:58 -0700 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 User-Agent: Thunderbird Reply-To: d@delphij.net Content-Language: en-US To: Ed Maste , freebsd-arch References: From: Xin Li Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------gJhiZ8yPb7FvajMHlA3DTjJV" X-Spamd-Result: default: False [-5.95 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-0.999]; NEURAL_HAM_SHORT(-0.96)[-0.961]; DMARC_POLICY_ALLOW(-0.50)[delphij.net,reject]; R_DKIM_ALLOW(-0.20)[delphij.net:s=m7e2]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,text/plain]; R_SPF_ALLOW(-0.20)[+mx]; MIME_BASE64_TEXT(0.10)[]; XM_UA_NO_VERSION(0.01)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[delphij]; REPLYTO_DOM_EQ_FROM_DOM(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; BLOCKLISTDE_FAIL(0.00)[2001:470:48ca:5:51a3:cfbd:9967:8fb6:server fail,2001:470:1:117::25:server fail]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; HAS_REPLYTO(0.00)[d@delphij.net]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; TO_DN_ALL(0.00)[]; HAS_ATTACHMENT(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; DKIM_TRACE(0.00)[delphij.net:+]; FROM_EQ_ENVFROM(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; RCVD_COUNT_TWO(0.00)[2]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~]; RCVD_TLS_ALL(0.00)[] X-Rspamd-Queue-Id: 4QB6fH2cQhz4Qsm X-Spamd-Bar: ----- X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------gJhiZ8yPb7FvajMHlA3DTjJV Content-Type: multipart/mixed; boundary="------------gpyFmo0hZcaR0A3HaFfjI5q6"; protected-headers="v1" From: Xin Li Reply-To: d@delphij.net To: Ed Maste , freebsd-arch Message-ID: Subject: Re: OpenSSL in the FreeBSD base system / FreeBSD 14 References: In-Reply-To: --------------gpyFmo0hZcaR0A3HaFfjI5q6 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 T24gMjAyMy0wNC0xOSA5OjUwIEFNLCBFZCBNYXN0ZSB3cm90ZToNCj4gVGhlcmUgaGF2ZSBi ZWVuIGEgZmV3IGRpc2N1c3Npb25zIG9uIHRoaXMgdG9waWMgaW4gZGlmZmVyZW50IHZlbnVl cywNCj4gYnV0IHdlIHNob3VsZCBjb25zb2xpZGF0ZSB0aGUgZGlzY3Vzc2lvbiBvbiBhIHB1 YmxpYyBtYWlsaW5nIGxpc3QuDQo+IFRoaXMgZW1haWwgcmVwcmVzZW50cyBhIHN1bW1hcnkg b2YgdGhlIGlzc3VlcyBhbmQgdGhlIGN1cnJlbnQgc3RhdGU7DQo+IHdl4oCZbGwgZGlzY3Vz cyBuZXh0IHN0ZXBzIGluIGZvbGxvdy11cCBtYWlsLg0KPiANCj4gRnJlZUJTRCAxNCBpcyBj b21pbmcgc29vbiwgYW5kIG9uZSBvdXRzdGFuZGluZyB0YXNrIGlzIGRlYWxpbmcgd2l0aA0K PiBPcGVuU1NMIGluIHRoZSBiYXNlIHN5c3RlbS4gVGhlIGJhc2Ugc3lzdGVtIGN1cnJlbnRs eSBoYXMgT3BlblNTTA0KPiAxLjEuMSwgYW5kIGl0IHdpbGwgYmUgRU9MIGFzIG9mIDIwMjMt MDktMTEuDQo+IA0KPiBUaGVyZSBhcmUgdHdvIHJlbGF0ZWQgaXNzdWVzOg0KPiANCj4gLSBU aGUgYmFzZSBzeXN0ZW0gbmVlZHMgdG8gbWlncmF0ZSBmcm9tIE9wZW5TU0wgMS4xLjEuDQo+ IC0gVGhlIHBvcnRzIGNvbGxlY3Rpb24gY3VycmVudGx5IG1ha2VzIHVzZSBvZiBPcGVuU1NM IHByb3ZpZGVkIGJ5IHRoZQ0KPiBiYXNlIHN5c3RlbSBieSBkZWZhdWx0LCB3aXRoIHNvbWUg ZXhjZXB0aW9ucy4NCj4gDQo+IENoYW5naW5nIHRoZSBiYXNlIHN5c3RlbSBPcGVuU1NMIGlu dG8gYSBwcml2YXRlbGliIHdvdWxkIGRlY291cGxlDQo+IHRoZXNlIHR3bywgc28gdGhhdCB0 aGUgYmFzZSBzeXN0ZW0gYW5kIHBvcnRzIGNhbiBtaWdyYXRlIHRvIE9wZW5TU0wgMw0KPiAo b3IgZXZlbiB0byBvdGhlciBpbXBsZW1lbnRhdGlvbnMpIG9uIHRoZWlyIG93biBzY2hlZHVs ZXMuIFdlIGhhdmUgYQ0KPiBudW1iZXIgb2YgcHJpdmF0ZWxpYnMgdG9kYXksIGxpa2UgbGli ZXZlbnQsIHRoYXQgYXJlIHVzZWQgYnkgdGhlIGJhc2UNCj4gc3lzdGVtIGJ1dCBub3QgYnkg cG9ydHMuIEFsbCBPcGVuU1NMLXVzaW5nIHBvcnRzIHdpbGwgbmVlZA0KPiBzZWN1cml0eS9v cGVuc3NsIChvciBhbm90aGVyIG9wZW5zc2wgcG9ydCkuDQo+IA0KPiBBIHJlbGF0ZWQgaXNz dWUgaXMgYmFzZSBzeXN0ZW0gbGlicmFyaWVzIHRoYXQgZGVwZW5kIG9uIE9wZW5TU0wgd291 bGQNCj4gYWxzbyBuZWVkIHRvIGJlIG1hZGUgcHJpdmF0ZS4gVGhpcyBpbmNsdWRlcyBnc3Nh cGksIGhlaW1kYWwsIGFuZA0KPiBsaWJmZXRjaC4NCj4gDQo+IFRoaXMgbGVhdmVzIHRoZSBh Y3R1YWwgdGFzayBvZiB1cGRhdGluZyBPcGVuU1NMIGluIHRoZSBiYXNlIHN5c3RlbSwNCj4g d2hpY2ggaXMgY29tcGxpY2F0ZWQgYmVjYXVzZSB3ZSB1c2UgYmVzcG9rZSBidWlsZCBpbmZy YXN0cnVjdHVyZSBpbg0KPiBjcnlwdG8vb3BlbnNzbC8gcmF0aGVyIHRoYW4gdGhlIHVwc3Ry ZWFtIGJ1aWxkIGJpdHMuIEZvciBiZXR0ZXIgb3INCj4gd29yc2UgdGhpcyBpcyB0aGUgdHlw aWNhbCBjYXNlIGZvciBhbGwgb2Ygb3VyIGNvbnRyaWIgc29mdHdhcmUsIGJ1dA0KPiBPcGVu U1NMIGlzIHBhcnRpY3VsYXJseSB0cmlja3kgYXMgaXQgbWFrZXMgdXNlIG9mIGEgbGFyZ2Ug bnVtYmVyIG9mDQo+IGdlbmVyYXRlZCBmaWxlcywgYW5kIHRob3NlIGZpbGVzIGFyZSBnZW5l cmF0ZWQgdXNpbmcgUGVybCBhbmQgcGVyaGFwcw0KPiBvdGhlciB0b29scyB0aGF0IGFyZSBu b3QgYXZhaWxhYmxlIGluIHRoZSBGcmVlQlNEIGJhc2Ugc3lzdGVtLiBQb3J0aW5nDQo+IHRo aXMgdG8gdGhlIGJhc2Ugc3lzdGVtIGlzIG5vdCBpbnN1cm1vdW50YWJsZSwgYnV0IHJlcXVp cmVzIGEgZmFpcmx5DQo+IGxhcmdlIGFtb3VudCBvZiB0ZWRpb3VzIHdvcmsuDQo+IA0KPiBU aGlzIHNob3VsZCBzZXJ2ZSBhcyBhIHNuYXBzaG90IG9mIHdoZXJlIHdlIGFyZSB0b2RheSBh bmQgYSBzdGFydGluZw0KPiBwb2ludCBmb3IgZGlzY3Vzc2lvbjsgd2XigJlsbCBmb3JtdWxh dGUgYSBsaXN0IG9mIHNwZWNpZmljIHRhc2tzIGluIGENCj4gZm9sbG93LXVwLg0KDQpQZXJz b25hbGx5IEkgdGhpbmsgaXQncyBub3QgYSB2ZXJ5IGdvb2QgaWRlYSB0byBtYWtlIGJhc2Ug T3BlblNTTCANCnByaXZhdGVsaWIsIGJlY2F1c2UgaXQgd291bGQgY29tcGxpY2F0ZSB0aGlu Z3MgYSBsb3QgKGFuZCB0aGluayBhYm91dCANCndoZW4gdGhlcmUgaXMgYSBTQSBmb3IgT3Bl blNTTCwgdGhlIHVzZXIgd291bGQgbm93IGhhdmUgdG8gYnVpbGQgT3BlblNTTCANCmZyb20g cG9ydCBhbmQgYmFzZSB0byBwYXRjaCB0aGVpciBzeXN0ZW1zKS4gIEl0IGlzIG11Y2ggc2xv d2VyIHRvIGdldCBhIA0Kc2V0IG9mIHBhY2thZ2VzIHJlYWR5IHdoZW4gbGlicmFyaWVzIGxp a2UgT3BlblNTTCwgZ2V0dGV4dCwgZXRjLiBnZXRzIGFuIA0KdXBkYXRlLCBjb21wYXJlZCB0 byBhcHBseWluZyBhIGJpbmFyeSB1cGRhdGUgdG8gdGhlIGJhc2Ugc3lzdGVtLg0KDQpIb3dl dmVyIGlmIHdlIGRvIGdvIHdpdGggdGhlIHByaXZhdGVsaWIgcm91dGUsIGl0J3MgYWxzbyBh biBvcHBvcnR1bml0eSANCnRvIGV4cGxvcmUgb3RoZXIgYWx0ZXJuYXRpdmVzIGxpa2UgTGli cmVTU0wgKGJlY2F1c2Ugd2Ugd291bGQgaGF2ZSBtb3JlIA0KZmxleGliaWxpdHkgb24gd2hh dCB3ZSBkbyB3aXRoIHRoZSBiYXNlIGxpYnJhcnkpLiAgU29sdmluZyBzeW1ib2wgDQpjb25m bGljdHMgc2hvdWxkIGJlIHBvc3NpYmxlIGJ1dCBkb2VzIGluY3VyIGFuIG9uZ29pbmcgYnVy ZGVuIG9mIA0KbWFpbnRlbmFuY2UsIGUuZy4gd2UgY291bGQgI2RlZmluZSB0aGUgZXhwb3J0 ZWQgc3ltYm9scyB0byBoYXZlIGEgDQpwcmVmaXgsIGxpa2Ugd2hhdCB3YXMgZG9uZSBmb3Ig bGlibWQsIGFuZCB0aGUgbGlzdCBvZiBleHBvcnRlZCBzeW1ib2xzIA0KY2FuIGJlIGV4dHJh Y3RlZCB3aXRoIG5tKDEpLg0KDQpDaGVlcnMsDQoNCg== --------------gpyFmo0hZcaR0A3HaFfjI5q6-- --------------gJhiZ8yPb7FvajMHlA3DTjJV Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEceNg5NEMZIki80nQQHl/fJX0g08FAmRSAM4FAwAAAAAACgkQQHl/fJX0g08x mRAAp87GGS0bYyZqc8CylPDsDwARP8qROFsvtUvJnHTcRdjHTweQjUI69dtaXQPX+BvqXE8sz1KD 3tBg0/2xR57fHS6yXhU9wnx4oSyc38nbvUolAoht8GkFqS8jxZGvXfOBoHCdjJrMA1tSHgimsNmA EfMnku7VGTPVKu4H6y1FcVeSNTVwiiAHamN/X+xG9XGOERK2kT3gZ0J2LNOxV5zYLn5/QHLDpKrM bsULJLHEnCNq75d9lvfJC+HBIkKQf2+pQck067CmUxWNXipq01soQfNGQ/eA50661GGHxt4xaXZt DrNA+70sJfS9+rsMNY19MITr/B2GTTLnGCFx+mzgnrhKZtiy5mlsYanG2rv2Z8GmbQevBRcZNLLR zh7qgPoMkex22rv+14VQNjNNfN6Q6c2IXQT7iTebzSOwt9i9UbRoI4GORgEwCUpCGNQCv9C2stpl AIyT6NNNS1DiaRa6WMi/S+xqBzWqj7fUWRNulqiz/MFO0IlrVCHJkpP8rPNFRzCBy7uYlHLk2CSv jN+gyJIXUna5roicqazUv009u+gWLQOxUy52nZRgXfhDBREqoRxwvGbU1fHstwwjpAhELamlJBoe kdWand2TTAaSD4CLXsBMwlFc9PDw0M4hIbwC5P+9gKzLQ5GibKP3okCIsY92Paw095/coXjUG+z/ DM4= =KNC9 -----END PGP SIGNATURE----- --------------gJhiZ8yPb7FvajMHlA3DTjJV-- From nobody Wed May 3 23:02:52 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 4QBXjH1NS6z49N83 for ; Wed, 3 May 2023 23:10:11 +0000 (UTC) (envelope-from freebsd-arch@m.gmane-mx.org) Received: from ciao.gmane.io (ciao.gmane.io [116.202.254.214]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBXjF53nwz47Ng for ; Wed, 3 May 2023 23:10:09 +0000 (UTC) (envelope-from freebsd-arch@m.gmane-mx.org) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of freebsd-arch@m.gmane-mx.org designates 116.202.254.214 as permitted sender) smtp.mailfrom=freebsd-arch@m.gmane-mx.org; dmarc=none Received: from list by ciao.gmane.io with local (Exim 4.92) (envelope-from ) id 1puLbl-0007lr-QT for freebsd-arch@freebsd.org; Thu, 04 May 2023 01:10:01 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-arch@freebsd.org From: Pierre Pronchery Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Date: Thu, 4 May 2023 01:02:52 +0200 Organization: FreeBSD Foundation Message-ID: References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> 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 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US In-Reply-To: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> X-Spamd-Result: default: False [1.17 / 15.00]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.993]; NEURAL_HAM_SHORT(-0.85)[-0.848]; MV_CASE(0.50)[]; FORGED_SENDER(0.30)[pierre@freebsdfoundation.org,freebsd-arch@m.gmane-mx.org]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_LONG(0.01)[0.011]; MIME_TRACE(0.00)[0:+]; FROM_NEQ_ENVFROM(0.00)[pierre@freebsdfoundation.org,freebsd-arch@m.gmane-mx.org]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:24940, ipnet:116.202.0.0/16, country:DE]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; RCVD_TLS_LAST(0.00)[]; HAS_ORG_HEADER(0.00)[]; DMARC_NA(0.00)[freebsdfoundation.org]; ARC_NA(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; FROM_HAS_DN(0.00)[]; TO_DN_NONE(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QBXjF53nwz47Ng X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N Hi everyone, On 5/2/23 23:24, John Baldwin wrote: > On 5/2/23 2:59 AM, Antoine Brodin wrote: >> On Tue, May 2, 2023 at 1:55 AM Enji Cooper wrote: >>> >>> Hello, >>> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL >>> 3.0 into the base system. This is a must because, in short, OpenSSL >>> 1.1 is no longer supported as of 09/26/2023 [1]. >>> >>> I am proposing OpenSSL be made private along with all dependent >>> libraries, for the following reasons: >>> 1. More than a handful of core ports, e.g., security/py-cryptography >>> [2] [3], still do not support OpenSSL 3.0. >>> i. If other dependent ports (like lang/python38, etc) move to OpenSSL >>> 3, the distributed modules would break on load due to clashing >>> symbols if the right mix of modules were dlopen’ed in a specific >>> order (importing ssl, then importing hazmat’s crypto would fail). >>> ii. Such ports should be deprecated/marked broken as I’ve recommended >>> on the 3.0 exp-run PR [4]. >>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in >>> both libraries at runtime impossible without resorting to a number of >>> linker tricks hiding the namespaces using symbol prefixing of public >>> symbols, etc. >>> >>> The libraries which would need to be made private are as follows: >>> - kerberos >>> - libarchive >>> - libbsnmp >>> - libfetch [5] >>> - libgeli >>> - libldns >>> - libmp >>> - libradius >>> - libunbound >> >> In my opinion this is a huge amount of work a few weeks before the >> release.  Focusing on updating OpenSSL and those core ports may be >> simpler. > > This is my view.  I think making OpenSSL private is a very huge task, and > fraught with peril in ways that haven't been thought about yet (e.g. PAM) > and that we can't hold up OpenSSL 3 while we wait for this.  Instead, I > think > we need to be moving forward with OpenSSL 3 in base as-is.  We will have to > fix ports to work with OpenSSL 3 regardless (though this does make that > pain > in ports happen sooner).  Moving libraries private can happen orthogonally > with getting base to work with OpensSL 3. I have started to look at updating OpenSSL to version 3.0.8 in base, using the existing vendor/openssl-3.0 branch. My progress can be found at https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I regularly force-push to keep a consistent and nice commit history, before possibly applying for a merge. So far the status is: - libssl, libcrypto build on amd64, i386, less sure about aarch64, other architectures not tested - libfetch builds, uses libmd in addition to OpenSSL - libradius builds, same thing - libarchive builds - libunbound builds, but not unbound - libmp builds I used libmd to reach a buildable status faster, since the equivalent MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in OpenSSL 3, we can avoid the dependency on libmd again. (anyone got sample code for this?) Meanwhile I keep trying to build the rest of the system, hopefully in time for a possible inclusion in -14. Reviews and tests on the whole thing will be more than welcome in any case! Cheers & HTH, -- Pierre Pronchery From nobody Wed May 3 23:36:24 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 4QBYJ76kVLz49PKd for ; Wed, 3 May 2023 23:36:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ed1-x530.google.com (mail-ed1-x530.google.com [IPv6:2a00:1450:4864:20::530]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBYJ750xPz49GG for ; Wed, 3 May 2023 23:36:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ed1-x530.google.com with SMTP id 4fb4d7f45d1cf-50bc25f0c7dso9347660a12.3 for ; Wed, 03 May 2023 16:36:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20221208.gappssmtp.com; s=20221208; t=1683157014; x=1685749014; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=NAlIJuRha5kD9m55hw+fP2Ghez/hk47NeA2LtQnFhBU=; b=XsHnUNm+lFiX75SEawbTwJ5y03gkL6MPZFxawL4GscN+M8BSLHCdTMnbc/xM5PA8G1 TNJBTlQbBfUIxWKGZW9GbrhGWDz15sE6jYaJ5bco78zwsrNUQyyEsNQeqt6O1FioPuuW DU1yB8VJ2FMPVNxP3odOGb7+3Eg7BC5yXzwEXeGSCXixtT6jpNzTyiHwTnlHlTmYZYt2 MX2fjVDIEeP4CDOuvuCpr4HM3B7ma7OCPsKQ6vRZmbc5ehQjPV/mTmnpYhGC/cgF3b20 uGOM66awNNy9fsphdus9lEF7tuj2yZ03knacFHJwu+hEMst6ckCuOcMzDAFK7qdvdJ9t Ennw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683157014; x=1685749014; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=NAlIJuRha5kD9m55hw+fP2Ghez/hk47NeA2LtQnFhBU=; b=PaUeJ4NYCq2mlHR1EBqWBrHyXzDSzq827aupd4OTsR0gHaH8asYpPmTxxLz3YERpWC vzsbGfHBXPQwK6hFG+Z9tB2SURv1TxgpsNXOzam6245KxSO8de6tFjORJORPsik7JW4L TUx6tD03RtktCYGw07LqgIKZWgQpvmAxYwfOy9jt+hZnavUqYWj1cHp8uqe1oIkw4CFW GFZ9U2CSwXqmeqNHfG01KC327Q+uRPkS6FbH2j4rDI4NWzGv3efh38jHLVRbEYyt1mH6 GBpkJBhUBvCkOcA+a1xvuMY/nog7TJj3m50tEAjssL6T/gp9Kg8lS+VOAys4GOvK4O8U 3DjQ== X-Gm-Message-State: AC+VfDzSTZpsnHdTHoSyGFvpQWnKA++lXbW6FF8wOdNPQ0s4sCrN1UKg SoDWRnnTg12vKoCUxaTGYy6CrIlvHeMsMv1zi46XoWpsy1jzR8OH X-Google-Smtp-Source: ACHHUZ6u9RMjU+iAqOLNXFcESYhOhJXInYFCidn+4GrdM4Wi+PyxEAIK1LFe5KAck5Eo9ffigCxODh8KiT/EeUfPF+A= X-Received: by 2002:a17:907:ea2:b0:953:1fba:7803 with SMTP id ho34-20020a1709070ea200b009531fba7803mr5829794ejc.15.1683157013650; Wed, 03 May 2023 16:36:53 -0700 (PDT) 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 References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> In-Reply-To: From: Warner Losh Date: Wed, 3 May 2023 17:36:24 -0600 Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc To: Pierre Pronchery Cc: "freebsd-arch@freebsd.org" Content-Type: multipart/alternative; boundary="000000000000e673af05fad287be" X-Rspamd-Queue-Id: 4QBYJ750xPz49GG X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --000000000000e673af05fad287be Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, May 3, 2023, 5:10 PM Pierre Pronchery wrote: > Hi everyone, > > On 5/2/23 23:24, John Baldwin wrote: > > On 5/2/23 2:59 AM, Antoine Brodin wrote: > >> On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper > wrote: > >>> > >>> Hello, > >>> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL > >>> 3.0 into the base system. This is a must because, in short, OpenSSL > >>> 1.1 is no longer supported as of 09/26/2023 [1]. > >>> > >>> I am proposing OpenSSL be made private along with all dependent > >>> libraries, for the following reasons: > >>> 1. More than a handful of core ports, e.g., security/py-cryptography > >>> [2] [3], still do not support OpenSSL 3.0. > >>> i. If other dependent ports (like lang/python38, etc) move to OpenSSL > >>> 3, the distributed modules would break on load due to clashing > >>> symbols if the right mix of modules were dlopen=E2=80=99ed in a speci= fic > >>> order (importing ssl, then importing hazmat=E2=80=99s crypto would fa= il). > >>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve rec= ommended > >>> on the 3.0 exp-run PR [4]. > >>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in > >>> both libraries at runtime impossible without resorting to a number of > >>> linker tricks hiding the namespaces using symbol prefixing of public > >>> symbols, etc. > >>> > >>> The libraries which would need to be made private are as follows: > >>> - kerberos > >>> - libarchive > >>> - libbsnmp > >>> - libfetch [5] > >>> - libgeli > >>> - libldns > >>> - libmp > >>> - libradius > >>> - libunbound > >> > >> In my opinion this is a huge amount of work a few weeks before the > >> release. Focusing on updating OpenSSL and those core ports may be > >> simpler. > > > > This is my view. I think making OpenSSL private is a very huge task, a= nd > > fraught with peril in ways that haven't been thought about yet (e.g. PA= M) > > and that we can't hold up OpenSSL 3 while we wait for this. Instead, I > > think > > we need to be moving forward with OpenSSL 3 in base as-is. We will hav= e > to > > fix ports to work with OpenSSL 3 regardless (though this does make that > > pain > > in ports happen sooner). Moving libraries private can happen > orthogonally > > with getting base to work with OpensSL 3. > > I have started to look at updating OpenSSL to version 3.0.8 in base, > using the existing vendor/openssl-3.0 branch. > > My progress can be found at > https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I > regularly force-push to keep a consistent and nice commit history, > before possibly applying for a merge. > > So far the status is: > > - libssl, libcrypto build on amd64, i386, less sure about aarch64, other > architectures not tested > - libfetch builds, uses libmd in addition to OpenSSL > - libradius builds, same thing > - libarchive builds > - libunbound builds, but not unbound > - libmp builds > > I used libmd to reach a buildable status faster, since the equivalent > MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in > OpenSSL 3, we can avoid the dependency on libmd again. (anyone got > sample code for this?) > > Meanwhile I keep trying to build the rest of the system, hopefully in > time for a possible inclusion in -14. > > Reviews and tests on the whole thing will be more than welcome in any cas= e! > Cool. Id like to echo the namespace remapping suggestion. OpenSSL tends to be basically a leaf requirement. If we always remapping our in tree openssl, then if someone uses, say, libfetch and something else that requires openssl1, they can coexist in the same binary. Without the namespace remapping, we get a guaranteed conflict. It would increase our flexibility. And it could potentially be mfc'd if the old openssl were left as an optional component for people on stable stuck with it as a requirement. It would mitigate the EOL issues while giving an escape hatch that's not insane (modulo the elevated risk) I'll have to take a closer look at the branch. Warner Cheers & HTH, > -- > Pierre Pronchery > > > --000000000000e673af05fad287be Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, May 3, 2023, 5:10 PM Pierre Pronchery <pierre@freebsdfoundation.org> wrote:
=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Hi everyone,

On 5/2/23 23:24, John Baldwin wrote:
> On 5/2/23 2:59 AM, Antoine Brodin wrote:
>> On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper <yaneurab= eya@gmail.com> wrote:
>>>
>>> Hello,
>>> One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL
>>> 3.0 into the base system. This is a must because, in short, Op= enSSL
>>> 1.1 is no longer supported as of 09/26/2023 [1].
>>>
>>> I am proposing OpenSSL be made private along with all dependen= t
>>> libraries, for the following reasons:
>>> 1. More than a handful of core ports, e.g., security/py-crypto= graphy
>>> [2] [3], still do not support OpenSSL 3.0.
>>> i. If other dependent ports (like lang/python38, etc) move to = OpenSSL
>>> 3, the distributed modules would break on load due to clashing=
>>> symbols if the right mix of modules were dlopen=E2=80=99ed in = a specific
>>> order (importing ssl, then importing hazmat=E2=80=99s crypto w= ould fail).
>>> ii. Such ports should be deprecated/marked broken as I=E2=80= =99ve recommended
>>> on the 3.0 exp-run PR [4].
>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes link= ing in
>>> both libraries at runtime impossible without resorting to a nu= mber of
>>> linker tricks hiding the namespaces using symbol prefixing of = public
>>> symbols, etc.
>>>
>>> The libraries which would need to be made private are as follo= ws:
>>> - kerberos
>>> - libarchive
>>> - libbsnmp
>>> - libfetch [5]
>>> - libgeli
>>> - libldns
>>> - libmp
>>> - libradius
>>> - libunbound
>>
>> In my opinion this is a huge amount of work a few weeks before the=
>> release.=C2=A0 Focusing on updating OpenSSL and those core ports m= ay be
>> simpler.
>
> This is my view.=C2=A0 I think making OpenSSL private is a very huge t= ask, and
> fraught with peril in ways that haven't been thought about yet (e.= g. PAM)
> and that we can't hold up OpenSSL 3 while we wait for this.=C2=A0 = Instead, I
> think
> we need to be moving forward with OpenSSL 3 in base as-is.=C2=A0 We wi= ll have to
> fix ports to work with OpenSSL 3 regardless (though this does make tha= t
> pain
> in ports happen sooner).=C2=A0 Moving libraries private can happen ort= hogonally
> with getting base to work with OpensSL 3.

I have started to look at updating OpenSSL to version 3.0.8 in base,
using the existing vendor/openssl-3.0 branch.

My progress can be found at
https://github.com/khorben= /freebsd-src/tree/khorben/openssl-3.0. I
regularly force-push to keep a consistent and nice commit history,
before possibly applying for a merge.

So far the status is:

- libssl, libcrypto build on amd64, i386, less sure about aarch64, other architectures not tested
- libfetch builds, uses libmd in addition to OpenSSL
- libradius builds, same thing
- libarchive builds
- libunbound builds, but not unbound
- libmp builds

I used libmd to reach a buildable status faster, since the equivalent
MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in
OpenSSL 3, we can avoid the dependency on libmd again. (anyone got
sample code for this?)

Meanwhile I keep trying to build the rest of the system, hopefully in
time for a possible inclusion in -14.

Reviews and tests on the whole thing will be more than welcome in any case!=

= Cool. Id like to echo the namespace remapping suggestion.=C2=A0 OpenSSL ten= ds to be basically a leaf requirement.=C2=A0 If we always remapping our in = tree openssl, then if someone uses, say, libfetch and something else that r= equires openssl1, they can coexist in the same binary. Without the namespac= e remapping, we get a guaranteed conflict.

It would increase our flexibility. And it could potentia= lly be mfc'd if the old openssl were left as an optional component for = people on stable stuck with it as a requirement. It would mitigate the EOL = issues while giving an escape hatch that's not insane (modulo the eleva= ted risk)

I'll have = to take a closer look at the branch.=C2=A0

Warner

Cheers & HTH,
--
Pierre Pronchery


--000000000000e673af05fad287be-- From nobody Wed May 3 23:54:53 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 4QBYhv2D3sz49PRl for ; Wed, 3 May 2023 23:54:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBYhv1TFDz4DH3; Wed, 3 May 2023 23:54:55 +0000 (UTC) (envelope-from jhb@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683158095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AThH56ne+UwoJlv4AsN+wY4ZRs1PXqjrJ3/YRdwFPa8=; b=gDnVQSXW2AmpfXh9sExHVtKkrV97xfnVFagBeiAkDhuTWXFuD9BjK6I8MHGNhEnKPOy1To b7bBlMDZUcADxfIrDwwzVMtofoXUtBKUN1/5XPZj21KZozaATbgDp7/D/E7e6tLAIJCFom GT/ZHcybGpjHX/fBS2MIS4B35kLFs0JRcLrsZNYSHWTphRFeCFtgG/fcoo0Cp2qvSQvfeM S87cisCvXoTPhRWftymPQd3KBDikgsxGh4c0WcyYAzaN0fhAhMwJhcu10E7MQmio3YFPzP DS7O57UgYIIb355OJLj/GjwJvasVWklD24xxBw2By6W3SE62rhAbjFmQRz1FMQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683158095; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=AThH56ne+UwoJlv4AsN+wY4ZRs1PXqjrJ3/YRdwFPa8=; b=vCtRtrtscgVfG09/xUjxcLEDqVNYeOFcMZ6Ck5CP+qKAgSuw4PbVGaGCHGDV+1y3pVj2tk cxjnAz/h5n/YFYNJuTfs9FFK2dm+qyqexthlmnb3H5OnGuLgRCUvMZ1IpYzdqUuKB5qQCX xkaR5BMX+CHvbgeFML0T1tSEKRReXsacoyFXLJoDTYdadkayb4TgsBBGzIHw+WXcwlj5Sm KJE0PjAoKNxSlJU9z7TKi60HaBHdtNvy3yWCb1XMPS74rXujHT5YdCvSAvwBobMRf4eSTq jOuR8/cjhtRhP95hELi3NES/El5mclu1AfIsHPCcBEZy2AOZ5kNmjtrxDO3EjQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683158095; a=rsa-sha256; cv=none; b=kfiI9FkMrYaTGSJniEmh9r1Q+eGGaxgMgAaY25SHHFhG8l8NNMkXW35XBhcZPo9cn9za3z ikZBm0IVlLO21Iem1cOEc1uOXMzEFu5Wb6kM2ylrTut3XjRZTWBz/ArPLORIZbcvJdPCbq V7xtAJPN0GKI6/xioFvXXGOu9UxUMDAsPqwuSvFJJ/lyRlCyiYzUoKxA1C9XbzY0wVP71K rcfnC3kOpUDFgfRAfT9Bfff1DgnvAD4p1Ci7wlJBuKyoPhkCyH3q51irFSUrOX84O7cEJ2 0hi1rw+J1xwh37wz400K4eFQvqMrS88PRnFoMEsgl6QkoFAxFaZiBLSFEI5LxQ== Received: from [IPV6:2601:648:8680:16b0:a5f2:2d0:1e3c:acb4] (unknown [IPv6:2601:648:8680:16b0:a5f2:2d0:1e3c:acb4]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) (Authenticated sender: jhb) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QBYht5ZK8zx7l; Wed, 3 May 2023 23:54:54 +0000 (UTC) (envelope-from jhb@FreeBSD.org) Message-ID: Date: Wed, 3 May 2023 16:54:53 -0700 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Content-Language: en-US To: Pierre Pronchery , freebsd-arch@freebsd.org References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> From: John Baldwin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-ThisMailContainsUnwantedMimeParts: N On 5/3/23 4:02 PM, Pierre Pronchery wrote: > Hi everyone, > > On 5/2/23 23:24, John Baldwin wrote: >> On 5/2/23 2:59 AM, Antoine Brodin wrote: >>> On Tue, May 2, 2023 at 1:55 AM Enji Cooper wrote: >>>> >>>> Hello, >>>> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL >>>> 3.0 into the base system. This is a must because, in short, OpenSSL >>>> 1.1 is no longer supported as of 09/26/2023 [1]. >>>> >>>> I am proposing OpenSSL be made private along with all dependent >>>> libraries, for the following reasons: >>>> 1. More than a handful of core ports, e.g., security/py-cryptography >>>> [2] [3], still do not support OpenSSL 3.0. >>>> i. If other dependent ports (like lang/python38, etc) move to OpenSSL >>>> 3, the distributed modules would break on load due to clashing >>>> symbols if the right mix of modules were dlopen’ed in a specific >>>> order (importing ssl, then importing hazmat’s crypto would fail). >>>> ii. Such ports should be deprecated/marked broken as I’ve recommended >>>> on the 3.0 exp-run PR [4]. >>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in >>>> both libraries at runtime impossible without resorting to a number of >>>> linker tricks hiding the namespaces using symbol prefixing of public >>>> symbols, etc. >>>> >>>> The libraries which would need to be made private are as follows: >>>> - kerberos >>>> - libarchive >>>> - libbsnmp >>>> - libfetch [5] >>>> - libgeli >>>> - libldns >>>> - libmp >>>> - libradius >>>> - libunbound >>> >>> In my opinion this is a huge amount of work a few weeks before the >>> release.  Focusing on updating OpenSSL and those core ports may be >>> simpler. >> >> This is my view.  I think making OpenSSL private is a very huge task, and >> fraught with peril in ways that haven't been thought about yet (e.g. PAM) >> and that we can't hold up OpenSSL 3 while we wait for this.  Instead, I >> think >> we need to be moving forward with OpenSSL 3 in base as-is.  We will have to >> fix ports to work with OpenSSL 3 regardless (though this does make that >> pain >> in ports happen sooner).  Moving libraries private can happen orthogonally >> with getting base to work with OpensSL 3. > > I have started to look at updating OpenSSL to version 3.0.8 in base, > using the existing vendor/openssl-3.0 branch. > > My progress can be found at > https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I > regularly force-push to keep a consistent and nice commit history, > before possibly applying for a merge. > > So far the status is: > > - libssl, libcrypto build on amd64, i386, less sure about aarch64, other > architectures not tested > - libfetch builds, uses libmd in addition to OpenSSL > - libradius builds, same thing > - libarchive builds > - libunbound builds, but not unbound > - libmp builds > > I used libmd to reach a buildable status faster, since the equivalent > MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed in > OpenSSL 3, we can avoid the dependency on libmd again. (anyone got > sample code for this?) You can use the EVP_* API if desired. tools/cryto/cryptocheck.c has examples of using the EVP_* APIs for both "plain" hashes and HMAC constructions -- John Baldwin From nobody Thu May 4 03:38:00 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 4QBffQ64yPz49ZjC for ; Thu, 4 May 2023 03:38:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBffQ3rL7z3HZg; Thu, 4 May 2023 03:38:06 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pf1-x430.google.com with SMTP id d2e1a72fcca58-63b5465fc13so40889b3a.3; Wed, 03 May 2023 20:38:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683171484; x=1685763484; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=BoYi5FGfvsn+XZxGo6C9YRH1AoZuFRTV704HlUB2BU8=; b=ErhDtim6K0CgcYSWJ2YnkHdj1lYoLa8P7mqul4NGr16sA1y84/zzWvHDRUzhY/Nwaq WL+ukN7XaaBOT8tOdFaGHnuc7DGTN/jYx1+zAm44LxGk2UDoxz8k5WfFd1BIA1ufog/Y 96Rajs6uyNCGC9t2wqefRCa3+bD9wmU93iiWSOaUcNQkHMosv8pBuCFWkVnnLgITRj4I XF5CB5UczmpHLslcby+2+TXaXiqJ5d+YotPVELCIwpkX1JdmRVSMFGWsJ5lbHlWEsEl8 9b92805gZsFtHBhcnRT9fYobEcvT9ZG1wJ2Z3LCiu06V1EtfQLgrOTK1mGL+YeYU+Wro NI2Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683171484; x=1685763484; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=BoYi5FGfvsn+XZxGo6C9YRH1AoZuFRTV704HlUB2BU8=; b=XgFfyLKmbhn3vUCSBFWH1BY67tHC69lmMThlGKxv0MMD/CH8sr3QqGhhLh3nBOn6U5 D74e6gwH6BfdTDHo9yLxlgDkTci5M/uqvvRFmBNWLMkatjKmn/FYKmOBoHIg+SzcwENJ ss3bAwZ1AYaBH+U0cjBUHk0NLzAt8YL0R+2Xl/g22q4mTd57LIru0G3/4AK0YiOdGgWQ CFzlHNKmhNIeCfJxSco0d4XqVD10boyo1xCduQNIa0yPua4qzaonbAd4dD/tCNgkoHpA 4iSadbBSGrhSImV6rXm4J3yxn2V7VxoWmSafkN5A7wztKx3l9Y1n5WTStNIYSjZV6GP6 cb+w== X-Gm-Message-State: AC+VfDxa8WUZu80BU5hMQAbgN7MNUu7+imrFM9mcEarDnLBT94KY0LZ9 g8U+XXgf6/jOkzv0G2k/g08w6vfD5rK8uA== X-Google-Smtp-Source: ACHHUZ4PfxdTu7XHKpBptp/R+M3H5ndZmJ5/bd5Q9Vaw556RlEuzeOTKFpyeXkOjjEegfUXt8AjjlA== X-Received: by 2002:a05:6a20:8f1e:b0:ee:5625:662f with SMTP id b30-20020a056a208f1e00b000ee5625662fmr1061993pzk.22.1683171483588; Wed, 03 May 2023 20:38:03 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id 69-20020a621948000000b00634dde2992bsm24295830pfz.132.2023.05.03.20.38.02 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Wed, 03 May 2023 20:38:02 -0700 (PDT) From: Enji Cooper Message-Id: <0CA43F8D-E320-4537-AD89-5D10D21D31D8@gmail.com> Content-Type: multipart/signed; boundary="Apple-Mail=_137487B1-2513-48EF-B3CA-C852D95A0D13"; 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 (Mac OS X Mail 16.0 \(3696.120.41.1.3\)) Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Date: Wed, 3 May 2023 20:38:00 -0700 In-Reply-To: Cc: Pierre Pronchery , freebsd-arch@freebsd.org To: John Baldwin References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> X-Mailer: Apple Mail (2.3696.120.41.1.3) X-Rspamd-Queue-Id: 4QBffQ3rL7z3HZg X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_137487B1-2513-48EF-B3CA-C852D95A0D13 Content-Type: multipart/alternative; boundary="Apple-Mail=_C598F332-56AE-4CA6-A5BD-E944CA65F837" --Apple-Mail=_C598F332-56AE-4CA6-A5BD-E944CA65F837 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 3, 2023, at 4:54 PM, John Baldwin wrote: >=20 > On 5/3/23 4:02 PM, Pierre Pronchery wrote: >> Hi everyone, >> On 5/2/23 23:24, John Baldwin wrote: >>> On 5/2/23 2:59 AM, Antoine Brodin wrote: >>>> On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper = wrote: >>>>>=20 >>>>> Hello, >>>>> One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL >>>>> 3.0 into the base system. This is a must because, in short, = OpenSSL >>>>> 1.1 is no longer supported as of 09/26/2023 [1]. >>>>>=20 >>>>> I am proposing OpenSSL be made private along with all dependent >>>>> libraries, for the following reasons: >>>>> 1. More than a handful of core ports, e.g., = security/py-cryptography >>>>> [2] [3], still do not support OpenSSL 3.0. >>>>> i. If other dependent ports (like lang/python38, etc) move to = OpenSSL >>>>> 3, the distributed modules would break on load due to clashing >>>>> symbols if the right mix of modules were dlopen=E2=80=99ed in a = specific >>>>> order (importing ssl, then importing hazmat=E2=80=99s crypto would = fail). >>>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve = recommended >>>>> on the 3.0 exp-run PR [4]. >>>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking = in >>>>> both libraries at runtime impossible without resorting to a number = of >>>>> linker tricks hiding the namespaces using symbol prefixing of = public >>>>> symbols, etc. >>>>>=20 >>>>> The libraries which would need to be made private are as follows: >>>>> - kerberos >>>>> - libarchive >>>>> - libbsnmp >>>>> - libfetch [5] >>>>> - libgeli >>>>> - libldns >>>>> - libmp >>>>> - libradius >>>>> - libunbound >>>>=20 >>>> In my opinion this is a huge amount of work a few weeks before the >>>> release. Focusing on updating OpenSSL and those core ports may be >>>> simpler. >>>=20 >>> This is my view. I think making OpenSSL private is a very huge = task, and >>> fraught with peril in ways that haven't been thought about yet (e.g. = PAM) >>> and that we can't hold up OpenSSL 3 while we wait for this. = Instead, I >>> think >>> we need to be moving forward with OpenSSL 3 in base as-is. We will = have to >>> fix ports to work with OpenSSL 3 regardless (though this does make = that >>> pain >>> in ports happen sooner). Moving libraries private can happen = orthogonally >>> with getting base to work with OpensSL 3. >> I have started to look at updating OpenSSL to version 3.0.8 in base, >> using the existing vendor/openssl-3.0 branch. >> My progress can be found at >> https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I >> regularly force-push to keep a consistent and nice commit history, >> before possibly applying for a merge. >> So far the status is: >> - libssl, libcrypto build on amd64, i386, less sure about aarch64, = other >> architectures not tested >> - libfetch builds, uses libmd in addition to OpenSSL >> - libradius builds, same thing >> - libarchive builds >> - libunbound builds, but not unbound >> - libmp builds >> I used libmd to reach a buildable status faster, since the equivalent >> MD5_*() API is now deprecated in OpenSSL 3. If MD5 is still allowed = in >> OpenSSL 3, we can avoid the dependency on libmd again. (anyone got >> sample code for this?) >=20 > You can use the EVP_* API if desired. tools/cryto/cryptocheck.c has = examples > of using the EVP_* APIs for both "plain" hashes and HMAC constructions I'll echo this as well. This is what the library maintainers recommend = for crypto primitive algorithm =E2=80=9Cagility=E2=80=9D. Cheers, -Enji --Apple-Mail=_C598F332-56AE-4CA6-A5BD-E944CA65F837 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On = May 3, 2023, at 4:54 PM, John Baldwin <jhb@FreeBSD.org> = wrote:

On 5/3/23 4:02 PM, Pierre Pronchery wrote:
Hi = everyone,
On 5/2/23 23:24, John Baldwin wrote:
On 5/2/23 2:59 AM, = Antoine Brodin wrote:
On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper <yaneurabeya@gmail.com> wrote:

Hello,
One of the = must-haves for 14.0-RELEASE is the introduction of OpenSSL
3.0 into the base system. This is a must because, in short, = OpenSSL
1.1 is no longer supported as of 09/26/2023 = [1].

I am proposing OpenSSL be made private = along with all dependent
libraries, for the following = reasons:
1. More than a handful of core ports, e.g., = security/py-cryptography
[2] [3], still do not support = OpenSSL 3.0.
i. If other dependent ports (like = lang/python38, etc) move to OpenSSL
3, the distributed = modules would break on load due to clashing
symbols if the = right mix of modules were dlopen=E2=80=99ed in a specific
order (importing ssl, then importing hazmat=E2=80=99s crypto = would fail).
ii. Such ports should be deprecated/marked = broken as I=E2=80=99ve recommended
on the 3.0 exp-run PR = [4].
2. OpenSSL 1.1 and 3.0 have clashing symbols, which = makes linking in
both libraries at runtime impossible = without resorting to a number of
linker tricks hiding the = namespaces using symbol prefixing of public
symbols, = etc.

The libraries which would need to be = made private are as follows:
- kerberos
- = libarchive
- libbsnmp
- libfetch [5]
- libgeli
- libldns
- libmp
- libradius
- libunbound

In my opinion this is a huge = amount of work a few weeks before the
release.  = Focusing on updating OpenSSL and those core ports may be
simpler.

This is my = view.  I think making OpenSSL private is a very huge task, and
fraught with peril in ways that haven't been thought about = yet (e.g. PAM)
and that we can't hold up OpenSSL 3 while = we wait for this.  Instead, I
think
we = need to be moving forward with OpenSSL 3 in base as-is.  We will = have to
fix ports to work with OpenSSL 3 regardless = (though this does make that
pain
in ports = happen sooner).  Moving libraries private can happen = orthogonally
with getting base to work with OpensSL 3.
I have started to look at updating OpenSSL to = version 3.0.8 in base,
using the existing = vendor/openssl-3.0 branch.
My progress can be found at
https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0= . I
regularly force-push to keep a consistent and nice = commit history,
before possibly applying for a merge.
So far the status is:
- libssl, libcrypto build = on amd64, i386, less sure about aarch64, other
architectures= not tested
- libfetch builds, uses libmd in addition to = OpenSSL
- libradius builds, same thing
- = libarchive builds
- libunbound builds, but not unbound
- libmp builds
I used libmd to reach a = buildable status faster, since the equivalent
MD5_*() API = is now deprecated in OpenSSL 3. If MD5 is still allowed in
OpenSSL 3, we can avoid the dependency on libmd again. = (anyone got
sample code for this?)

You can use the EVP_* API if desired. =  tools/cryto/cryptocheck.c has examples
of using the EVP_* APIs for both = "plain" hashes and HMAC constructions

I'll echo this as well. This is what the = library maintainers recommend for crypto primitive algorithm = =E2=80=9Cagility=E2=80=9D.
Cheers,
-Enji
= --Apple-Mail=_C598F332-56AE-4CA6-A5BD-E944CA65F837-- --Apple-Mail=_137487B1-2513-48EF-B3CA-C852D95A0D13 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEtvtxN6kOllEF3nmX5JFNMZeDGN4FAmRTKJkACgkQ5JFNMZeD GN71jQ/+NE9kOX+9cWIZVEAiKxdVZ819KQh1xX7f0+05aTzZD+JvyNBnytDJPOkF ORn1x04nQvVcrAS1RQSMfIfsUJuh5p4uPV7UvyLYTR8UWuz9wrLywEPrcQTq8LVb FrYNz8F2Sk887WTB1e+uaxUDcLzWNhAf0Yp3YesHV30TiX2gkQnIrmKP/ANMReTO Lt2LTtpQTNmMfug6eB418goTEIKBDuaJlynTGgeFObO/fuvfXZD4R+/JCYzVEOm7 RjnbRoMTKd9UCElWMHTaVr2BQpa3pWixk/VNJJs2xGDGnawn1RLLOvSehwF+8R2R gWYlpvLliQnG24ew5y2ctnIcb8Z6fqv2OUIhcW1VngpGDmwiPMtbuDr3jVo0r+Eh x8NyUQkONjOnsPpJEc8OEPZM4KnaN3FZ6QMMCeHv7q7WZ64KSNWPPhIRysIyeTfV i/fwZgDvgcMJOpBgTKXJQ5d61WxxHkNpj92RXTz9OmXk57adpy5kYuytoT46XOSe BJHVJrAXiogByeFaMo8OmaLlSFgUd4cBz8oZIsOjcmbMS1CvSNLVTgVxIudZNE7e wLDD4PqxmDbggGn+p4ft28fTFPbzAw6JZ6+UGsu/7YVUawX2GoTZaiwO5TdXBn8T csW8QkYB5fgUB/C82L2Aze2i18WcP6XmkzXSZ5pOFEz3Ume5yUU= =5yrL -----END PGP SIGNATURE----- --Apple-Mail=_137487B1-2513-48EF-B3CA-C852D95A0D13-- From nobody Thu May 4 16:07:47 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 4QBzHY1GlHz49GBj for ; Thu, 4 May 2023 16:07:53 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBzHY0lFKz3mqh; Thu, 4 May 2023 16:07:53 +0000 (UTC) (envelope-from bofh@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683216473; 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=jc0Aurw8ZjUOvCNKaUZZzs5pydXz4vcwfX9umvf3RAE=; b=YTAfckdcRyrqAORdXwx7KWSUvKBKYugQEEosNzjr6RLjAdIFE47SiwdhqwiO+U9FIZ7Ky1 I7V6f6wEQFhuNJijo6wWnSHDUxAS2F9e6yvBBJ9Or+G7/eaTk2FZTl7qOu3TokgBk40+b7 gT+arDFxFIJCEF+cJNnBRaGGYs6iWlRYPiKV34tv5OdF9fMJgx+ONIHoyi5aZk1T8GOOEm b+0Jn7/szNYs3eJ+ycaUd2SDyx3lV8lLaUVaG+xZINn6vveLpfMeVXS4EmIWLB/nAygnnH +sjzAGm33zhMZ/bqqS5sobwagNq6WSDJQnda3JUvdD3FNJhZje5xo2Aux30U+g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1683216473; 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=jc0Aurw8ZjUOvCNKaUZZzs5pydXz4vcwfX9umvf3RAE=; b=BFS2ADMR4C8hQuLJeRyNsV1h6xnkKoNsy6Yz3ZRgGHUaCAjgqv+OuwZcMOaBieLFKddeXC AOSwK+v/H9BnwOs4kDL8sEwqzlM5IkKNnyHWVEcucw8R3CBjEkzvWAVHPir8PNjhsq72kC D7RHdOpTkSY5QpX3ZSiy2MLduezAHQ/OIBZnTw5yS18f/ZPz0sAhybapgbfJt8xKqS7UNj yhKBjPgpNuhCIj5vpYWPeLK5au3weDqC3yAxp/znftG5nNgb57cCuS8uXNhILqbZc6JzFz VR62Ja44DRyrDIWIJQyiv/RtjolsbBt3QD2Udq3Qdn9lkKwHtdWe67W1hGM/sw== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1683216473; a=rsa-sha256; cv=none; b=B1kaljDmFXgPD7UuYnh/PhLH9XndYpGgmaUfNCrKL2qKAC8b6+x6lP+mWF3zEGZwAnT9Vl LV7tRvNl2ciSJ37pVSq9tULmJrXLZbKJyHi0/WSDY6/SSiiyooN1Oh1UBr+KG5EYlzZVHW i6GyLi/YGZ4pokudprGAjmUdNjINwQdrmG2ubAfaz25YRC4s+UuX9lbsS2iCS4GFXPUdBI 0nM/BiUOfwu//n4F8TC9hgH+FkGY5p8Z5v+24yBB0zHKS8Bjm9p27GKjZx6EFytD0gEOsT 4b9b/Hssl3VGJMrgk6Tkcd3bcz/E7owoE18BnShlYt271jiLC1y+mtPsZDQcgQ== Received: from mx.bofh.network (mx.bofh.network [IPv6:2a01:4f8:261:25de::227]) (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 "mx.bofh.network", Issuer "R3" (verified OK)) (Authenticated sender: bofh/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 4QBzHX1Bqrz1DNk; Thu, 4 May 2023 16:07:52 +0000 (UTC) (envelope-from bofh@freebsd.org) Received: from smtpclient.apple (gw.office.cyso.net [95.97.78.194]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id 7202cc9a (TLSv1.2:ECDHE-ECDSA-AES256-GCM-SHA384:256:NO); Thu, 4 May 2023 16:07:50 +0000 (UTC) From: Moin Rahman Message-Id: <4733AD1A-7954-4B79-9789-A57A0B46C71B@freebsd.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_9D0700B7-AE03-4465-AE0D-777B38B5EADB" 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 (Mac OS X Mail 16.0 \(3696.120.41.1.1\)) Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Date: Thu, 4 May 2023 18:07:47 +0200 In-Reply-To: Cc: FreeBSD-arch list , Bernard Spil , Cy Schubert , Ed Maste , vishwin@freebsd.org, portmgr To: Enji Cooper References: X-Mailer: Apple Mail (2.3696.120.41.1.1) X-ThisMailContainsUnwantedMimeParts: N --Apple-Mail=_9D0700B7-AE03-4465-AE0D-777B38B5EADB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On May 3, 2023, at 3:14 AM, Moin Rahman wrote: >=20 >=20 >=20 >> On May 2, 2023, at 3:55 AM, Enji Cooper = wrote: >>=20 >> Hello, >> One of the must-haves for 14.0-RELEASE is the introduction of = OpenSSL 3.0 into the base system. This is a must because, in short, = OpenSSL 1.1 is no longer supported as of 09/26/2023 [1]. >>=20 >> I am proposing OpenSSL be made private along with all dependent = libraries, for the following reasons: >> 1. More than a handful of core ports, e.g., = security/py-cryptography [2] [3], still do not support OpenSSL 3.0. >> i. If other dependent ports (like lang/python38, etc) = move to OpenSSL 3, the distributed modules would break on load due to = clashing symbols if the right mix of modules were dlopen=E2=80=99ed in a = specific order (importing ssl, then importing hazmat=E2=80=99s crypto = would fail). >> ii. Such ports should be deprecated/marked broken as = I=E2=80=99ve recommended on the 3.0 exp-run PR [4]. >> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes = linking in both libraries at runtime impossible without resorting to a = number of linker tricks hiding the namespaces using symbol prefixing of = public symbols, etc. >>=20 >> The libraries which would need to be made private are as = follows: >> - kerberos >> - libarchive >> - libbsnmp >> - libfetch [5] >> - libgeli >> - libldns >> - libmp >> - libradius >> - libunbound >>=20 >> I realize I=E2=80=99m jumping to a prescribed solution without = additional discussion, but I=E2=80=99ve been doing offline analysis = related to uplifting code from OpenSSL 1.x to 3.x over the last several = months and this is the general prescribed solution I=E2=80=99ve come to = which is needed for $work. My perspective might have some blind spots = and some of the discussion done over IRC and might need to be rehashed = here for historical reference/to widen the discussion for alternate = solutions that don=E2=80=99t have the degree of tunnel vision which the = solution I=E2=80=99m employing at $work requires. >> I=E2=80=99ve tried to include some of the previously involved = parties so they can chime in. >> Thank you, >> -Enji >>=20 >> 1. https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/ >> 2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . >> 3. The reason why it hasn=E2=80=99t been upgraded is because newer = versions require rustc to build, which apparently doesn=E2=80=99t work = on QEMU builders due to missing emulation support: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 . >> 4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15 >> 5. If I remember correctly, some folks suggested that making libfetch = private wasn=E2=80=99t required since the only port that required it was = ports-mgmt/pkg, but I haven=E2=80=99t validated this claim. >=20 > Hi Enji, >=20 > I appreciate your work creating the bugs but please hold on a moment = before you create the bugs. It will slow me down. >=20 > While you were wasting your time creating the ticket for nrpe3 I have = already updated the port to 4.1.0 to unbreak. So until I have the final = list which you will have by end of this week please do not create = tickets. >=20 > And I have not exactly described the process too what I was doing. The = list you are getting in my poudriere might have two possible failure = reason. OpenSSL 3 or LLVM15; and some might be fixed with little = intervention and testing. And as it's not possible to ask poudriere not = to try BROKEN ports so I have marked some port as blacklisted which are = unfixable or broken for other reasons. If you really would like to = create tickets and chase upstream please do: > find /usr/local/poudriere/ports/default -name Makefile -type f -d 3 = -exec grep -E '(BROKEN_SSL\=3D|IGNORE_SSL\=3D).*openssl3' {} \+ >=20 > Thanks for your cooperation. Hi, I have completed my final partial exp-run with ports that has USES=3Dssl = in any form and the result is available from here: = https://pkg.bofh.network/build.html?mastername=3DMAIN-default-openssl3&bui= ld=3D2023-05-04_16h25m58s You will see some blacklisted ports which fails to build on all = supported RELEASE or HEAD. Apart from that I have tried to fix up as = much as possible ports by updating/changing. I will not run anymore = exp-run until we have a proper OSVERSION and OpenSSL 3.0.0 vendor branch = merged into base and fix those ports that has BROKEN_SSL=3Dopenssl30 to = conditionally mark BROKEN with ssl=3Dbase. If someone wants to chase the upstreams of the ports feel free to do so. During fixing these issues I had to upgrade some of the ports with = portmgr(blanket) approval and in case if you think that I have = overstepped on your plannings I apologies for that. However desperate = time needs desperate measures. Now I will go backup fixing LLVM15 issues with 14.0-RELEASE and ports. Kind regards, Moin= --Apple-Mail=_9D0700B7-AE03-4465-AE0D-777B38B5EADB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On May 3, 2023, at 3:14 AM, Moin Rahman <bofh@freebsd.org> = wrote:



On May 2, 2023, at 3:55 = AM, Enji Cooper <yaneurabeya@gmail.com> wrote:

Hello,
One of the must-haves for = 14.0-RELEASE is the introduction of OpenSSL 3.0 into the base system. = This is a must because, in short, OpenSSL 1.1 is no longer supported as = of 09/26/2023 [1].

I am = proposing OpenSSL be made private along with all dependent libraries, = for the following reasons:
1. More than a handful of core = ports, e.g., security/py-cryptography [2] [3], still do not support = OpenSSL 3.0.
i. If other dependent ports (like = lang/python38, etc) move to OpenSSL 3, the distributed modules would = break on load due to clashing symbols if the right mix of modules were = dlopen=E2=80=99ed in a specific order (importing ssl, then importing = hazmat=E2=80=99s crypto would fail).
ii. Such = ports should be deprecated/marked broken as I=E2=80=99ve recommended on = the 3.0 exp-run PR [4].
2. OpenSSL 1.1 and 3.0 have = clashing symbols, which makes linking in both libraries at runtime = impossible without resorting to a number of linker tricks hiding the = namespaces using symbol prefixing of public symbols, etc.

The libraries which would need to = be made private are as follows:
- = kerberos
- libarchive
- = libbsnmp
- libfetch [5]
- = libgeli
- libldns
- = libmp
- libradius
- = libunbound

I realize I=E2=80=99m jumping to = a prescribed solution without additional discussion, but I=E2=80=99ve = been doing offline analysis related to uplifting code from OpenSSL 1.x = to 3.x over the last several months and this is the general prescribed = solution I=E2=80=99ve come to which is needed for $work. My perspective = might have some blind spots and some of the discussion done over IRC and = might need to be rehashed here for historical reference/to widen the = discussion for alternate solutions that don=E2=80=99t have the degree of = tunnel vision which the solution I=E2=80=99m employing at $work = requires.
I=E2=80=99ve tried to include = some of the previously involved parties so they can chime in.
Thank you,
-Enji

1. = https://www.openssl.org/blog/blog/2023/03/28/1.1.1-EOL/
2. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 = .
3. The reason why it hasn=E2=80=99t been upgraded is = because newer versions require rustc to build, which apparently = doesn=E2=80=99t work on QEMU builders due to missing emulation support: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D254853 = .
4. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D258413#c15<= /a>
5. If I remember correctly, some folks suggested that = making libfetch private wasn=E2=80=99t required since the only port that = required it was ports-mgmt/pkg, but I haven=E2=80=99t validated this = claim.

Hi Enji,

I appreciate your work creating the bugs but = please hold on a moment before you create the bugs. It will slow me = down.

While you were wasting your time = creating the ticket for nrpe3 I have already updated the port to 4.1.0 = to unbreak. So until I have the final list which you will have by end of = this week please do not create tickets.

And = I have not exactly described the process too what I was doing. The list = you are getting in my poudriere might have two possible failure reason. = OpenSSL 3 or LLVM15; and some might be fixed with little intervention = and testing. And as it's not possible to ask poudriere not to try BROKEN = ports so I have marked some port as blacklisted which are unfixable or = broken for other reasons. If you really would like to create tickets and = chase upstream please do:
find = /usr/local/poudriere/ports/default -name Makefile -type f -d 3 -exec = grep -E '(BROKEN_SSL\=3D|IGNORE_SSL\=3D).*openssl3' {} \+

Thanks for your cooperation.

Hi,

I have completed my final partial = exp-run with ports that has USES=3Dssl in any form and the result is = available from here:
https://pkg.bofh.network/build.html?mastername=3DMAIN-default-o= penssl3&build=3D2023-05-04_16h25m58s

You will see some blacklisted ports = which fails to build on all supported RELEASE or HEAD. Apart from that I = have tried to fix up as much as possible ports by updating/changing. I = will not run anymore exp-run until we have a proper OSVERSION and = OpenSSL 3.0.0 vendor branch merged into base and fix those ports that = has BROKEN_SSL=3Dopenssl30 to conditionally mark BROKEN with = ssl=3Dbase.

If = someone wants to chase the upstreams of the ports feel free to do = so.

During = fixing these issues I had to upgrade some of the ports with = portmgr(blanket) approval and in case if you think that I have = overstepped on your plannings I apologies for that. However desperate = time needs desperate measures.

Now I will go backup fixing LLVM15 = issues with 14.0-RELEASE and ports.

Kind regards,
Moin
= --Apple-Mail=_9D0700B7-AE03-4465-AE0D-777B38B5EADB-- From nobody Thu May 4 16:30:45 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 4QBzpD4Pcyz49HWg for ; Thu, 4 May 2023 16:31:00 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pl1-x635.google.com (mail-pl1-x635.google.com [IPv6:2607:f8b0:4864:20::635]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QBzpC698cz3vc7; Thu, 4 May 2023 16:30:59 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-pl1-x635.google.com with SMTP id d9443c01a7336-1aad55244b7so5042405ad.2; Thu, 04 May 2023 09:30:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683217858; x=1685809858; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=JoBbX44k49QxDUFDuu8LvbhlRhLlmtoJ2JoZ+cFoQbA=; b=PUxM/hcp2gW8uXyzcLaFCu98OC5VhFqR/xdZgkJhNr7RUi82v2EIANl+vatGgy88ng Sq01Czd+8T5akTx20MP3jqg7HfyVEUISEtPLLS5VxeFmUaOU0IR7TcldiS0j9eKQUqeV 9wakM2nQ9HzCgAMkxDhfoSOi+z6opn1yLHnlDF+D/JnlE9TAx4HKy7t7rTVFc9/jrE7U 7Gv4c8gCFpx8AkahAxI9u2k7/Uyc0Js7EuN4e/7q/xULwquTasLD0oPLNM4wiM+31qd8 OI0PPAN1w0pQd9Y3WgtyJEOC1DPW4UhpbIrR/PWGs/avSlQuLbhbcq81/LXgwmPVdTXO iSuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683217858; x=1685809858; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=JoBbX44k49QxDUFDuu8LvbhlRhLlmtoJ2JoZ+cFoQbA=; b=emm3wjspmlDQmk5wkBbkGPlldGao3xaI93K8qt2ElrQYJxqKDvJrGg6xmhTfMfUimG Jc3n10VPLzgZwmjyry3URanpuduB8HDXpQXGG+trOxyrApF3KqcdkRiVA6+oi4ekW8HV WAclu4pxew5+l3Cgp+Tj0j4rVrtbepcivi6+jmict9iPLABb8UQoweimCMNv+umyv2Km G1tqK33sz1kFdRYKNz0ePOuVK1wzpnr8Skjtu09kMzL0zn/OhYvQALobnSizNfjrQi3U IUuscfZPGuST77oDxRWj4Adzve5GI9fx0NgSvSmmU3IB8p2bpRQYKJ+cR2+hiaH52kcp ouQA== X-Gm-Message-State: AC+VfDxA17O4/9yoBu8d43IglxZqpiXh9IiWkj4Joo4sFrBp+fFWRgwY Y+7YRitNJGsmaHK6TKtmjvEYUq2gJw0f8Q== X-Google-Smtp-Source: ACHHUZ6eKfDB1xqRZ3ubEhyzUysfkhNItPrzUY0zU0lEICgoaCXMc7yQ+Q6hCA9MgQIkezX5v7zFjg== X-Received: by 2002:a17:903:18f:b0:1a9:6bd4:236a with SMTP id z15-20020a170903018f00b001a96bd4236amr5124823plg.69.1683217857631; Thu, 04 May 2023 09:30:57 -0700 (PDT) Received: from smtpclient.apple (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id j13-20020a170902c3cd00b001a6d4ffc760sm4073874plj.244.2023.05.04.09.30.56 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 04 May 2023 09:30:57 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: Enji Cooper 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 (1.0) Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc Date: Thu, 4 May 2023 09:30:45 -0700 Message-Id: <4D1AF540-5A02-45A2-8DD0-70209F639C66@gmail.com> References: Cc: freebsd-arch@freebsd.org, andrew@freebsd.org In-Reply-To: To: Pierre Pronchery X-Mailer: iPhone Mail (20D67) X-Rspamd-Queue-Id: 4QBzpC698cz3vc7 X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N > On May 3, 2023, at 16:10, Pierre Pronchery w= rote: >=20 > =EF=BB=BF Hi everyone, >=20 >> On 5/2/23 23:24, John Baldwin wrote: >>> On 5/2/23 2:59 AM, Antoine Brodin wrote: >>> On Tue, May 2, 2023 at 1:55=E2=80=AFAM Enji Cooper wrote: >>>>=20 >>>> Hello, >>>> One of the must-haves for 14.0-RELEASE is the introduction of OpenSSL 3= .0 into the base system. This is a must because, in short, OpenSSL 1.1 is no= longer supported as of 09/26/2023 [1]. >>>>=20 >>>> I am proposing OpenSSL be made private along with all dependent librari= es, for the following reasons: >>>> 1. More than a handful of core ports, e.g., security/py-cryptography [2= ] [3], still do not support OpenSSL 3.0. >>>> i. If other dependent ports (like lang/python38, etc) move to OpenSSL 3= , the distributed modules would break on load due to clashing symbols if the= right mix of modules were dlopen=E2=80=99ed in a specific order (importing s= sl, then importing hazmat=E2=80=99s crypto would fail). >>>> ii. Such ports should be deprecated/marked broken as I=E2=80=99ve recom= mended on the 3.0 exp-run PR [4]. >>>> 2. OpenSSL 1.1 and 3.0 have clashing symbols, which makes linking in bo= th libraries at runtime impossible without resorting to a number of linker t= ricks hiding the namespaces using symbol prefixing of public symbols, etc. >>>>=20 >>>> The libraries which would need to be made private are as follows: >>>> - kerberos >>>> - libarchive >>>> - libbsnmp >>>> - libfetch [5] >>>> - libgeli >>>> - libldns >>>> - libmp >>>> - libradius >>>> - libunbound >>>=20 >>> In my opinion this is a huge amount of work a few weeks before the >>> release. Focusing on updating OpenSSL and those core ports may be >>> simpler. >> This is my view. I think making OpenSSL private is a very huge task, and= >> fraught with peril in ways that haven't been thought about yet (e.g. PAM)= >> and that we can't hold up OpenSSL 3 while we wait for this. Instead, I t= hink >> we need to be moving forward with OpenSSL 3 in base as-is. We will have t= o >> fix ports to work with OpenSSL 3 regardless (though this does make that p= ain >> in ports happen sooner). Moving libraries private can happen orthogonall= y >> with getting base to work with OpensSL 3. >=20 > I have started to look at updating OpenSSL to version 3.0.8 in base, using= the existing vendor/openssl-3.0 branch. >=20 > My progress can be found at https://github.com/khorben/freebsd-src/tree/kh= orben/openssl-3.0. I regularly force-push to keep a consistent and nice comm= it history, before possibly applying for a merge. >=20 > So far the status is: >=20 > - libssl, libcrypto build on amd64, i386, less sure about aarch64, other a= rchitectures not tested > - libfetch builds, uses libmd in addition to OpenSSL > - libradius builds, same thing > - libarchive builds > - libunbound builds, but not unbound > - libmp builds >=20 > I used libmd to reach a buildable status faster, since the equivalent MD5_= *() API is now deprecated in OpenSSL 3. If MD5 is still allowed in OpenSSL 3= , we can avoid the dependency on libmd again. (anyone got sample code for th= is?) >=20 > Meanwhile I keep trying to build the rest of the system, hopefully in time= for a possible inclusion in -14. >=20 > Reviews and tests on the whole thing will be more than welcome in any case= ! I=E2=80=99ll take a look at your fork/branch and pitch in some of the areas y= ou mentioned above where you switched to libmd, etc. One thing that I noticed which was potentially a sticking point was the aarc= h64 support. I=E2=80=99m not sure if you ran into this as well, but someone w= ith aarch64/arm64 expertise will need to help validate the branch/changes on= that platform family. Thanks! -Enji= From nobody Fri May 5 13:38:25 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 4QCWww3vhHz49LNk; Fri, 5 May 2023 13:38:40 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lj1-f178.google.com (mail-lj1-f178.google.com [209.85.208.178]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QCWwv0yTDz3QW1; Fri, 5 May 2023 13:38:39 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.178 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-lj1-f178.google.com with SMTP id 38308e7fff4ca-2ac8d9399d5so1956231fa.1; Fri, 05 May 2023 06:38:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683293917; x=1685885917; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=0a2yu3ZV/04YR7xugxE7nV5wxaL+v7kRUY7APxX/EXk=; b=fG4y/Q4Btgm58YSpCMkUvMdrHUFXZmuPGzQ8pH+Knok6L6nXLiCjpYKCLbf2l91Z++ r7UcOljBvfR0lH332IcfCuKhNttoZxdDCvxqhtMNy9flzmFoP2XkNLDZX0xKfjev7XFK sOoTsEWRmISE7ZyLAkCdSeYE7xHCh+STazFLinhSN7Rrs9uso6rNf1xbe+amOGjrT9Ub rhtObAgBSk55f7rIPUI5FLb8Q3dX/b6F+xVDysfte8SF5BJj6IC1Bf9nemt1tQAXFClm 7+58DSPtQBkeyHqmz+XFzLhIzYfw3xa+yMWK28WT1LbgsH7+F4ZAZIdLFFPiHR3waS9d rPPg== X-Gm-Message-State: AC+VfDxV8/w4/ErbJ1TkmPEea2C7AmO0WtBnZ6j/roDUJuOI49jhjPK6 kl880mfal1CpTavCqDVc6LS4pH7uagK+iBIPHXjQ1hJ8 X-Google-Smtp-Source: ACHHUZ4m0YfFys0UyVNmSoyQ8LUkbLnN6/XOUN9W2b5guGu9MVwxZJQ24s7iEK7Dk+AgDASMYqYAvfWW6qWO63fC4Y0= X-Received: by 2002:a2e:964c:0:b0:2a7:7259:9587 with SMTP id z12-20020a2e964c000000b002a772599587mr442581ljh.46.1683293916821; Fri, 05 May 2023 06:38:36 -0700 (PDT) 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 From: Ed Maste Date: Fri, 5 May 2023 09:38:25 -0400 Message-ID: Subject: Support for more than 256 CPU cores To: freebsd-arch , FreeBSD Current Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Result: default: False [1.17 / 15.00]; NEURAL_SPAM_SHORT(0.57)[0.572]; NEURAL_SPAM_LONG(0.52)[0.520]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_MEDIUM(0.07)[0.073]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org,freebsd-current@freebsd.org]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.178:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.178:from]; FREEMAIL_ENVFROM(0.00)[gmail.com]; R_DKIM_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_ALL(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; BLOCKLISTDE_FAIL(0.00)[209.85.208.178:server fail]; FROM_HAS_DN(0.00)[]; RCVD_TLS_LAST(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; DMARC_NA(0.00)[freebsd.org]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QCWwv0yTDz3QW1 X-Spamd-Bar: + X-ThisMailContainsUnwantedMimeParts: N FreeBSD supports up to 256 CPU cores in the default kernel configuration (on Tier-1 architectures). Systems with more than 256 cores are available now, and will become increasingly common over FreeBSD 14=E2=80=99= s lifetime. The FreeBSD Foundation is supporting the effort to increase MAXCPU, and PR269572[1] is open to track tasks and changes. As a project we have scalability work ahead of us to make best use of high core count machines, but at a minimum we should be able to boot a GENERIC kernel on such systems, and have an ABI for the FreeBSD 14 release that supports such a configuration. Some changes have already been committed in support of increased MAXCPU, including increasing MAX_APIC_ID (commit c8113dad7ed4) and a number of changes to reduce bloat (such as commits 42f722e721cd, e72f7ed43eef, 78cfa762ebf2 and 74ac712f72cf). The next step is to increase the maximum cpuset size for userland. I have this change open in review D39941[2] and an exp-run request in PR271213[3]. Following that the kernel change for increasing MAXCPU is in D36838[4]. Additional work on bloat reduction will continue after this change, and looking forward FreeBSD is going to need ongoing effort from the community and the FreeBSD Foundation to continue improving scalability. [1] https://bugs.freebsd.org/269572 [2] https://reviews.freebsd.org/D39941 [3] https://bugs.freebsd.org/271213 [4] https://reviews.freebsd.org/D36838 From nobody Fri May 5 15:52:29 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 4QCZvP0hGFz49Tb0; Fri, 5 May 2023 15:52:33 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (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 4QCZvN5R7rz43KD; Fri, 5 May 2023 15:52:32 +0000 (UTC) (envelope-from hps@selasky.org) Authentication-Results: mx1.freebsd.org; none Received: from [10.36.2.154] (unknown [46.212.121.255]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 8CADD260734; Fri, 5 May 2023 17:52:29 +0200 (CEST) Message-ID: <84816f2f-b23c-f448-55fe-454cbb604681@selasky.org> Date: Fri, 5 May 2023 17:52:29 +0200 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:102.0) Gecko/20100101 Thunderbird/102.10.1 Subject: Re: Support for more than 256 CPU cores To: Tomek CEDRO , Ed Maste Cc: freebsd-arch , FreeBSD Current References: Content-Language: en-US From: Hans Petter Selasky In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4QCZvN5R7rz43KD X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:24940, ipnet:2a01:4f8::/32, country:DE] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On 5/5/23 17:23, Tomek CEDRO wrote: > On Fri, May 5, 2023 at 3:38 PM Ed Maste wrote: >> FreeBSD supports up to 256 CPU cores in the default kernel configuration >> (on Tier-1 architectures). Systems with more than 256 cores are >> available now, and will become increasingly common over FreeBSD 14’s >> lifetime. (..) > > Congratulations! :-) > > I am looking after AMD Threadripper with 64 cores 2 threads each that > will give 128 CPU to the system.. maybe this year I could afford that > beast then I will report back after testing :-) > > In upcoming years variations of RISC-V will provide unheard before > number of CPU in a single SoC (i.e. 1000 CPU) at amazing power > efficiency and I saw reports of prototype with 3 x SoC of this kind on > a single board :-) > > https://spectrum.ieee.org/risc-v-ai > Hi, Maybe it makes sense to cluster CPU's in logical groups somehow. Some synchronization mechanism like EPOCH() are O(N²) where N is the number of CPUs. Not in the read-case, but in the synchronize case. It depends a bit though. Currently EPOCH() is executed every kern.hz . --HPS From nobody Fri May 5 20:03:15 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 4QChSx5YWzz49kWy for ; Fri, 5 May 2023 20:03:29 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lj1-f179.google.com (mail-lj1-f179.google.com [209.85.208.179]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4QChSw6ZLZz3MVS for ; Fri, 5 May 2023 20:03:28 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of carpeddiem@gmail.com designates 209.85.208.179 as permitted sender) smtp.mailfrom=carpeddiem@gmail.com; dmarc=none Received: by mail-lj1-f179.google.com with SMTP id 38308e7fff4ca-2ac831bb762so18695581fa.3 for ; Fri, 05 May 2023 13:03:28 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683317007; x=1685909007; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2dMuLP5qZ44ipzJ0V3iJIPCO7bn0U7XH6Rm7zwr0WTE=; b=bVHeYAM+eGCR0ooMTfsqmmtqEpBi93+yxO6yT4h62mnMJ+jZcshnRDOyukHjnDZmYu CZ3jK18/UnQjx5Aw3zkLR59tOzOCyZGiwFEgqcGare7zZIMILj4ECzMMx1gce9FHZ0nU qLWQQwKfTl1MDk1+B1ZZXXez03JKEyK1p9fU8Bq+evmcxE9HC81Bj125WVyrdONkH5c7 j0RqDLL416rVsboSTXccTEdWlURNFvSDitA1L+kPoqE1riOQAbDhcB21nBeZUwCKumKL O3oieR6JKjEY/FJ25n2vDnYpeSNkFhIbI1Pe21B3El2gv+Bh95AWaQcWLazDT9ZiDbLD VL/A== X-Gm-Message-State: AC+VfDwn64iboCC3JideT8QEjkhTinf9EpVVsViQ9gAs/IP/78ag3slC bAM9ClYHaa+etbTme0PtEUilQOwMC9nwdFzFqhI= X-Google-Smtp-Source: ACHHUZ5HP9LORasfvDBhrVcU1L63dJfCX2XeCQSNrJ4BsDZE/wTNAo9GhRfyqbLQM5ZppJ+FIDZahs1Q6eUKgHGii20= X-Received: by 2002:a05:6512:1031:b0:4dd:98c6:ee2 with SMTP id r17-20020a056512103100b004dd98c60ee2mr712071lfr.15.1683317006704; Fri, 05 May 2023 13:03:26 -0700 (PDT) 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 References: <12f8559c-d696-5344-98d5-1751d04088af@FreeBSD.org> In-Reply-To: From: Ed Maste Date: Fri, 5 May 2023 16:03:15 -0400 Message-ID: Subject: Re: OpenSSL 3.0 for 14.0-RELEASE: issues with 1.x/3.x symbol clashing, ports linking against base OpenSSL, ports that don't compile/link against OpenSSL 3, etc To: Pierre Pronchery Cc: freebsd-arch@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Spamd-Result: default: False [-0.59 / 15.00]; NEURAL_HAM_SHORT(-0.64)[-0.642]; NEURAL_SPAM_LONG(0.37)[0.369]; NEURAL_HAM_MEDIUM(-0.32)[-0.318]; FORGED_SENDER(0.30)[emaste@freebsd.org,carpeddiem@gmail.com]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_ENVFROM(0.00)[gmail.com]; MLMMJ_DEST(0.00)[freebsd-arch@freebsd.org]; R_DKIM_NA(0.00)[]; FROM_NEQ_ENVFROM(0.00)[emaste@freebsd.org,carpeddiem@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.208.179:from]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; RCVD_IN_DNSWL_NONE(0.00)[209.85.208.179:from]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; FROM_HAS_DN(0.00)[]; FREEFALL_USER(0.00)[carpeddiem]; ARC_NA(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[freebsd.org]; PREVIOUSLY_DELIVERED(0.00)[freebsd-arch@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-Rspamd-Queue-Id: 4QChSw6ZLZz3MVS X-Spamd-Bar: / X-ThisMailContainsUnwantedMimeParts: N On Wed, 3 May 2023 at 19:10, Pierre Pronchery wrote: > > I have started to look at updating OpenSSL to version 3.0.8 in base, > using the existing vendor/openssl-3.0 branch. > > My progress can be found at > https://github.com/khorben/freebsd-src/tree/khorben/openssl-3.0. I > regularly force-push to keep a consistent and nice commit history, > before possibly applying for a merge. > > So far the status is: > > - libssl, libcrypto build on amd64, i386, less sure about aarch64, other > architectures not tested aarch64 is also Tier-1 and we'll need to make sure it's working well, but that can happen after we have at least one arch fully functional. > - libfetch builds, uses libmd in addition to OpenSSL > - libradius builds, same thing > - libarchive builds > - libunbound builds, but not unbound > - libmp builds I had a look at the remaining build failures with your changes merged in, and I see errors due to deprecation notices in: auditdistd bhyve decryptcore dma dumpon factor ktls_test ldns libfido2 ppp telnet tcpdump I started working on updating libfido2 some time ago, and will pick that back up.