In D41614#948592, @delphij wrote:

The change looks Okay to me but I wonder if we should separate the variable into two cached values, one for new and the other for !new.

When changing multiple providers at the same time, this would allow the library to cache both passphrases so the user don't have to enter them over and over again.

The change looks Okay to me but I wonder if we should separate the variable into two cached values, one for new and the other for !new.

Merged as https://reviews.freebsd.org/rGe4520c8bd1d3 .

Are there any objections to continuing with the creation of the vendor/openssl-3.0 branch?

In D38835#884813, @dim wrote:

In D38835#884784, @ngie wrote:

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

If openssl3 is going to be a private lib, then ports can't use it at all, right? I see there is already security/openssl which is 1.1.1t, and security/openssl-devel which is 3.0.8 (strange, because the development version of OpenSSL is 3.1.0 but I digress). So ports would have to link against the former or the latter (and can't use both). Also, if we make a private openssl3 lib, we'll have to rename all symbols so as to not conflict with ports. Alternatively, the ports openssl versions should rename all _their_ symbols to not conflict. That might also solve the problem of mixing 1.1 and 3.0.

In any case, getting openssl3 in side-by-side is a good first step, allowing piecemeal work to be done.

In D38835#884784, @ngie wrote:

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

Part of what I would like to do based on informal discussions in IRC is to put OpenSSL 3 into its own subdirectory, make it into a private library (props goes to @dim for the idea!) and transition utilities in base over to OpenSSL 3, then work on the ports story with @brnrd .

In D38835#884625, @jkim wrote:

In D38835#884575, @ngie wrote:

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

Actually, we need to rewrite both FreeBSD-upgrade and FreeBSD-Xlist from scratch for OpenSSL 3.0 because it is quite different.

In D38835#884575, @ngie wrote:

I followed a different import process than what’s described in FreeBSD-UPGRADE because it was much simpler for me to use rsync -av —-delete to update the contents than multiple calls to find/tar/comm.

In D38835#884175, @emaste wrote:

I assume your vendor/openssl-3.0 branch started from the current vendor/openssl?

I assume your vendor/openssl-3.0 branch started from the current vendor/openssl?

https://reviews.freebsd.org/D16215 (+ https://reviews.freebsd.org/D16216 for IPsec and https://reviews.freebsd.org/D16219 for aesni(4) ) solves the problem generally.

I agree w/ cem that we need a general solution to this. I'm fine w/ this patch, but I do question the wisdom in making this code aesni only. This code really needs to be turned into a library which any OCF driver can use, as this performance problem is not limited to aesni.

In D15389#328653, @emeric.poupon_stormshield.eu wrote:

So what is the plan here? Wait for somebody willing to do the session management in OCF right?