Date: Mon, 25 Jan 2021 19:46:54 +0000 (UTC) From: Kostya Berger <bergerkos@yahoo.co.uk> To: FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: 13-alpha2 libncurses removal breaks ports build Message-ID: <985070144.9595325.1611604014395@mail.yahoo.com> In-Reply-To: <1384574721.390368.1611500021710@mail.yahoo.com> References: <992972141.8836030.1611441657314.ref@mail.yahoo.com> <992972141.8836030.1611441657314@mail.yahoo.com> <1384574721.390368.1611500021710@mail.yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Builds OK from inside clean install. Which is all I needed this far. Thank =
you.
With kindest regards,
Kostya Berger
=20
=20
On Sunday, 24 January 2021, 17:53:41 GMT+3, Kostya Berger <bergerkos@ya=
hoo.co.uk> wrote: =20
=20
OK, building ports against a clean installation of 13.0-ALPHA2 has no prob=
lem with ncurses.=20
But devel/glib20 fails for no obvious reason closer to the end of building =
process... I just wonder: do I need to report this to port maintainers or w=
ait till it settles up=C2=A0 somehow? A good deal of ports depend=C2=A0 on =
it.
With kindest regards,
Kostya Berger
=20
=20
On Sunday, 24 January 2021, 01:40:57 GMT+3, Kostya Berger <bergerkos@ya=
hoo.co.uk> wrote: =20
=20
Hi everyone,I don't seem to find any mentioning in the /usr/ports/UPDATING=
about how one should handle the removal of libncurses.so.9 from base.=20
Source UPDATING only says:ncurses installation has been modified to only ke=
ep the widechar
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 enabled version.=C2=A0 Increment=
al build is broken for that change, so it
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 requires a clean build.
If that means to just build all ports anew, then it doesn't work as ports d=
on't seem to incorporate any change related to this one. It would seem defa=
ult configuration should take into account this, but it doesn't.
The ports just use --with-libncurses-prefix=3D/usr, and there is no ncurses=
libs found there. This make it skip MOST of the ports I'm using.
Working Copy Root Path: /usr/ports
URL: https://svn.freebsd.org/ports/head
Relative URL: ^/head
Repository Root: https://svn.freebsd.org/ports
Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
Revision: 562417
Node Kind: directory
Schedule: normal
Last Changed Author: 0mp
Last Changed Rev: 562417
Last Changed Date: 2021-01-23 23:01:38 +0300 (Sat, 23 Jan 2021)
With kindest regards,
Kostya Berger
=20
=20
From owner-freebsd-current@freebsd.org Mon Jan 25 19:55:23 2021
Return-Path: <owner-freebsd-current@freebsd.org>
Delivered-To: freebsd-current@mailman.nyi.freebsd.org
Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1])
by mailman.nyi.freebsd.org (Postfix) with ESMTP id DA1C94EF559
for <freebsd-current@mailman.nyi.freebsd.org>;
Mon, 25 Jan 2021 19:55:23 +0000 (UTC) (envelope-from jhb@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 4DPgZg5ykwz3DpB;
Mon, 25 Jan 2021 19:55:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org)
Received: from John-Baldwins-MacBook-Pro.local (unknown
[IPv6:2601:648:8681:1cb0:5c12:2e91:6a1e:30bf])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(Client did not present a certificate) (Authenticated sender: jhb)
by smtp.freebsd.org (Postfix) with ESMTPSA id 78F8617BC;
Mon, 25 Jan 2021 19:55:23 +0000 (UTC) (envelope-from jhb@FreeBSD.org)
To: Neel Chauhan <nc@freebsd.org>, freebsd-current@freebsd.org
References: <bd56c9d3711738d65a074d73c04addd2@freebsd.org>
From: John Baldwin <jhb@FreeBSD.org>
Subject: Re: Can In-Kernel TLS (kTLS) work with any OpenSSL Application?
Message-ID: <77a3f82a-5235-f702-41d5-c1edafbab6c3@FreeBSD.org>
Date: Mon, 25 Jan 2021 11:55:22 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:78.0)
Gecko/20100101 Thunderbird/78.6.1
MIME-Version: 1.0
In-Reply-To: <bd56c9d3711738d65a074d73c04addd2@freebsd.org>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-BeenThere: freebsd-current@freebsd.org
X-Mailman-Version: 2.1.34
Precedence: list
List-Id: Discussions about the use of FreeBSD-current
<freebsd-current.freebsd.org>
List-Unsubscribe: <https://lists.freebsd.org/mailman/options/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-current/>;
List-Post: <mailto:freebsd-current@freebsd.org>
List-Help: <mailto:freebsd-current-request@freebsd.org?subject=help>
List-Subscribe: <https://lists.freebsd.org/mailman/listinfo/freebsd-current>,
<mailto:freebsd-current-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 25 Jan 2021 19:55:23 -0000
On 1/20/21 12:21 PM, Neel Chauhan wrote:
> Hi freebsd-current@,
>
> I know that In-Kernel TLS was merged into the FreeBSD HEAD tree a while
> back.
>
> With 13.0-RELEASE around the corner, I'm thinking about upgrading my
> home server, well if I can accelerate any SSL application.
>
> I'm asking because I have a home server on a symmetrical Gigabit
> connection (Google Fiber/Webpass), and that server runs a Tor relay. If
> you're interested in how Tor works, the EFF has a writeup:
> https://www.eff.org/pages/what-tor-relay
>
> But the main point for you all is: more-or-less Tor relays deal with
> 1000s TLS connections going into and out of the server.
>
> Would In-Kernel TLS help with an application like Tor (or even load
> balancers/TLS termination), or is it more for things like web servers
> sending static files via sendfile() (e.g. CDN used by Netflix).
It depends. Applications with allow OpenSSL to use a socket directly
(e.g. via SSL_set_fd() or via SSL_connect() or the like) will work with
kernel TLS transparently. This includes things like apache, nginx,
fetch, wget, curl, etc. However, some applications use OpenSSL purely
as a data transformation library and manage the socket I/O separately
(e.g. OpenVPN). KTLS will not work with these applications since
OpenSSL doesn't "know" about the socket in question.
> My server could also work with Intel's QuickAssist (since it has an
> Intel Xeon "Scalable" CPU). Would QuickAssist SSL be more helpful here?
You can use this with ktls_ocf.ko and the qat(4) drivers.
I am working, btw, on merging KTLS into base OpenSSL and hope to have
it present in 13.0.
As you noted, applications would need to be changed to use SSL_sendfile()
to get the best performance on TX. We don't really have an analog on
the receive side in our syscall API. One might be able to do some
creative things with aio_read(4) perhaps, but I haven't implemented that.
Also, currently RX offload always returns individual records with the
full TLS header via recvmsg(). Linux's RX offload only includes the
message for non-application-data messages so that one could in theory
do bulk read(2) calls larger than a single TLS record. OpenSSL itself
though always reads a single TLS record at a time, so if I were to change
this (e.g. with a new socket option to toggle headers for application
data), this would only be relevant to software that "knew" it was using
KTLS and would use direct read/write after letting OpenSSL (or a similar
library) handle the handshake.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?985070144.9595325.1611604014395>