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?

In D34579#828698, @glebius wrote:

I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail.

I can't see how this can be used maliciously, e.g. forcing some application outside of jail to send its SCM_RIGHTS to a jail. Even if such case exists for a certain application, that would be bug in that application, IMHO. The initial idea of SCM_RIGHTS was actually to grant rights intentionally, so there can be a valid case for a certain application that wants to grant rights to its peer in a jail.

For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail.

I'm going to have to sleep on the approach. This is a known escape, but I don't know if the method used can fully plug it. For example it is possible to share file descriptor tables, and one of the processes may not be encumbered by the jail. As is it does solve it for processes which have no way to talk to each other apart from a partially shared fs though.

I'll do the commit. Thanks to Greg for writing this and to everyone who helped to review it!

Who is going to do the actual commit? I'm happy to do it if no-one else wants to? Whoever does it has csprng@ green-light.

Last nit can be done pre-commit or I can whack it post-commit; ok from lua perspective.

Is this ready to be committed? I'm happy to do it myself but markm said he was going to commit (prior to the latest round of changes) -- don't want to commit prematurely if you're still waiting for something.

Yep, I've had basically the exact same opinion as @delphij about the copyright. Let's go with Intel.

So seems like it's easier to just do it all in core.lua, which is where lots of config accesses are anyway.

In D20780#766778, @greg_unrelenting.technology wrote:

err, I have not addressed the "isUEFIBoot" thing and the "This file needs a copyright / license at the top" thing…

err, I have not addressed the "isUEFIBoot" thing and the "This file needs a copyright / license at the top" thing…

Thanks! Can you also MFC it to stable/13 after a week?

In D20780#766643, @cperciva wrote:

Is this waiting for anything else before it gets committed?

Is this waiting for anything else before it gets committed?