Maybe this should be split into two reviews: (1) Basic funtionality for the base system, (2) adding links in LOCALBASE?

In D49130#1132354, @jrm wrote:

It's indeed running in a chroot.

% sudo procstat -f $(pgrep local-unbound)
  PID COMM                FD T V FLAGS    REF  OFFSET PRO NAME
 3763 local-unbound     text v r r-------   -       - -   /usr/sbin/local-unbound
 3763 local-unbound      cwd v d r-------   -       - -   /var/unbound
 3763 local-unbound     root v d r-------   -       - -   /var/unbound
 3763 local-unbound     jail v d r-------   -       - -   /var/unbound
 3763 local-unbound        0 v c rw------   3       0 -   /dev/null
 3763 local-unbound        1 v c rw------   3       0 -   /dev/null
 3763 local-unbound        2 v c rw------   3       0 -   /dev/null
 3763 local-unbound        3 s - rw---n--   1       0 UDP ::1.53 ::.0
 3763 local-unbound        4 s - rw---n--   1       0 TCP 0 0 ::1.53 ::.0
 3763 local-unbound        5 s - rw---n--   1       0 UDP 127.0.0.1:53 *:0
 3763 local-unbound        6 s - rw---n--   1       0 TCP 0 0 127.0.0.1:53 *:0
 3763 local-unbound        7 s - rw---n--   1       0 UDS 0 0 /var/run/local_unbound.ctl
 3763 local-unbound        8 s - rw------   1       0 UDD /var/run/log
 3763 local-unbound        9 s - rw---n--   1       0 UDS 0 0 -
 3763 local-unbound       10 s - rw---n--   1       0 UDS 0 0 -

In D49130#1132352, @jrm wrote:

Sorry. I'm struggling to keep up with a lot of requests these days.

% rg tls /var/unbound/unbound.conf
9:      tls-system-cert: yes

I can confirm that without the ca_root_nss package installed, local_unbound will not resolve unless the certificate bundle is installed as /etc/ssl/cert.pem. With the certificate bundle present, it will resolve and truss output shows:

88570: open("/etc/ssl/cert.pem",O_RDONLY,0666)   = 8 (0x8)

Does that answer your questions?

@jrm , yet another ping: Where you able to test this with local_unbound?

No reaction from secteam...

I am fine with that.

MFC'ed and issue created: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=285546

@jrm, did you get a chance to test that with local unbound?

Add improvements from @jrm.

Fix invalid test condition

In D49402#1126581, @jrm wrote:

In D49402#1126472, @michaelo wrote:

@jrm, yes of course, it simply worked in poudriere. Did forget to bump the revision.

In D49402#1126478, @michaelo wrote:

I don't know who represents maintainer apache@FreeBSD.org, but I guess I have to give the potential maintainers two weeks of time for this.

It's a mailing list [0] so proceed as you see fit.

[0] https://lists.freebsd.org/subscription/freebsd-apache

Merged.

I don't know who represents maintainer apache@FreeBSD.org, but I guess I have to give the potential maintainers two weeks of time for this.

@jrm, yes of course, it simply worked in poudriere. Did forget to bump the revision.

In D49294#1125562, @emaste wrote:

Who is supported to cherry-pick to releng?

Secteam will do that. You can just fill out the erratum template and mail it to secteam.

In D49294#1124889, @kevans wrote:

Awesome, thanks! Let me know if you need help with the process- I'd like others to be comfortable with updating the caroot bundle as I'd never intended to be the long-term maintainer of it, but I've failed repeatedly to entice anyone else into dealing with it.

In D49130#1124975, @jrm wrote:

In D49130#1124947, @michaelo wrote:

In D49130#1124932, @jrm wrote:

Thanks for this. I still had ca_root_nss installed because local_unbound configured with TLS required a certificate bundle. Unbound with TLS is now working without ca_root_nss.

Regarding unbound, if you set tls-system-cert to true you will have the default truststore enabled: https://github.com/NLnetLabs/unbound/blob/5c84bb573f9728c10bcb3592dbd12be403d362de/util/net_help.c#L1593-L1601

Only chroot requires a bundle which sitll can use tls-system-cert.

In my opinion the unbound in base should have this option set to true by default to reduce the user headache.

In D49130#1124947, @michaelo wrote:

In D49130#1124932, @jrm wrote:

Thanks for this. I still had ca_root_nss installed because local_unbound configured with TLS required a certificate bundle. Unbound with TLS is now working without ca_root_nss.

Regarding unbound, if you set tls-system-cert to true you will have the default truststore enabled: https://github.com/NLnetLabs/unbound/blob/5c84bb573f9728c10bcb3592dbd12be403d362de/util/net_help.c#L1593-L1601

Only chroot requires a bundle which sitll can use tls-system-cert.

In my opinion the unbound in base should have this option set to true by default to reduce the user headache.

Please confirm, but I believe if you put something like this in /etc/rc.conf:

local_unbound_enable="YES"
local_unbound_forwarders="x.x.x.x@853#xxx"
local_unbound_tls="YES"

Then run # service local_unbound setup, you will get that option in /var/unbound/unbound.conf and it will use a chroot, so you do need the bundle.

Will work on EN after MFC.

Address @jrm's comments

In D49130#1124932, @jrm wrote:

Thanks for this. I still had ca_root_nss installed because local_unbound configured with TLS required a certificate bundle. Unbound with TLS is now working without ca_root_nss.

In D49130#1124932, @jrm wrote:

Thanks for this. I still had ca_root_nss installed because local_unbound configured with TLS required a certificate bundle. Unbound with TLS is now working without ca_root_nss.

In D49294#1124887, @kevans wrote:

In D49294#1124880, @michaelo wrote:

In D49294#1124877, @kevans wrote:

This looks reasonable to me, thanks! We'll want an associated EN, as well- are you OK with preparing for that?

I must admit that I have no idea how to create an EN. Whould that apply only to stable branches?

So we can MFC these kinds of changes to stable/ branches without overhead, but we then submit EN to get secteam@ to roll them into patch releases following MFC. You can use the pre-existing caroot EN you pointed at for most of the fields, but you'd want to grab a fresh copy of the EN template in case there's some verbiage updates int he parts that we don't fill out: https://www.freebsd.org/security/errata-template.txt -- the completed template then gets attached to a new bugzilla PR for secteam to track (I think we can just file a new "Base System" > misc PR for "Bundled caroot in existing releases is out of date", attach the template then assign it to secteam@ with the "needs_errata" flag set).

Are you talking about https://www.freebsd.org/security/advisories/FreeBSD-EN-23:11.caroot.asc?

In D49294#1124877, @kevans wrote:

This looks reasonable to me, thanks! We'll want an associated EN, as well- are you OK with preparing for that?

Guys, can you have a look?

Followup review: https://reviews.freebsd.org/D49327

In D49299#1124539, @ziaee wrote:

Is there any action required by the administrator from this change? E.g., they'll just seamlessly have updated manpages?

Just tested devel/talloc, suffers from the same problem as net/samba4*, another manpage is installed. When XSLTPROC is properly disabled, the build fails. So, I guess, several, at least, other Samba-related ports require fixing.

Enable MANPAGES by default

These seem MANPAGES not to have on by default:

./audio/libsndfile/Makefile
./databases/ldb25/Makefile
./databases/ldb28/Makefile
./databases/ldb29/Makefile
./databases/libmemcached/Makefile
./databases/pxlib/Makefile
./databases/tdb/Makefile
./databases/tdb1410/Makefile
./deskutils/xdg-desktop-portal/Makefile
./deskutils/xdg-terminal-exec/Makefile
./devel/json-glib/Makefile
./devel/ocaml-dolmen/Makefile
./devel/schilybase/Makefile
./devel/talloc/Makefile
./devel/talloc242/Makefile
./devel/tcllib/Makefile
./devel/tevent/Makefile
./devel/tevent016/Makefile
./devel/universal-ctags/Makefile
./graphics/libavif/Makefile
./math/alt-ergo/Makefile
./multimedia/dvdauthor/Makefile
./ports-mgmt/appstream-generator/Makefile
./security/git-crypt/Makefile
./sysutils/conky/Makefile
./sysutils/gnome-power-manager/Makefile
./sysutils/polkit/Makefile

In D49299#1124382, @jrm wrote:

Do we want to go from installing man pages by default to not installing them by default?

There used to be a section in the Porter's Handbook that said something along the lines of man pages should be unconditionally installed. (If it's still there, I can't find it.) I think options like MANPAGES were added as an exception for when generating the man pages requires some bloated dependency. I recall @mat has strong opinions about this, so I'll add him here.

@phk This is what I was writing you privately...

Remove also expired untrusted roots

@jrm , do you accept your own proposal formally?

Mentors, any opinion?

Hope to remove patch when upstream accepts it.

In D45073#1123386, @ziaee wrote:

I think this communicates an important caveat in a terse, informative, and specific way.

In D49191#1123316, @ehaupt wrote:

In D49191#1123307, @michaelo wrote:

@ehaupt, do you want to close this out as a user problem and not a port problem?

Yes. I'd like to do that. If the user wants to have a static version without any port readline or gettext he can simply rebuild shells/bash-static without those options. Sure, no pre-built pkgs but that's just the way it is.

@ehaupt, do you want to close this out as a user problem and not a port problem?

Rust maintainers, please have a look. This is quite annoying issue especially because it is hard to diagnose from a high level perspective.

Recommendation is out, have another look.

Update with @jrm's proposal

Incorporate @jrm's comment

In D49075#1123116, @emaste wrote:

certdata.txt uses unfortunately a two-digit year

Yeah, that's the sad part

I will leave other a few more days to review.

In D49075#1123105, @emaste wrote:

$year + 100 makes me sad :(

Fix formatting

I'd like to MFC it after a week.

Distrust after 398 days as requested by @emaste