In D50052#1141942, @jrm wrote:

In D50052#1141939, @jrm wrote:

This fixes a build problem, so you can commit with implicit maintainer approval.

I see some people use implicit portgmr approval when fixing builds. For example, 7d61294c3546ec94549b2f75e14c2e3c2ca09791. I'm not sure whether this is documented anywhere.

Waiting for port maintainer's consent.

Build error in poudriere:

In D49130#1140705, @heliosyne_gmail.com wrote:

In D49130#1140593, @michaelo wrote:

In D49130#1133049, @heliosyne_gmail.com wrote:

In D49130#1132911, @michaelo wrote:

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

ok.

14.3-RELEASE is approach. Can you please split up? I want to have this at least for base in the next release.

If the change doesn't provide full replacement functionality for ca_root_nss, it defeats the purpose. If someone else wants to butcher this they can do so. But this process has been utterly disheartening and has made me doubt the value of contributing at all. I'd rather keep my local changes local from now on if this is what sharing gets me.

I'd also like to personally thank Franco for their efforts as they've led to me finding a replacement for OPNsense.

Please don't resubscribe me to this diff.

In D49130#1133049, @heliosyne_gmail.com wrote:

In D49130#1132911, @michaelo wrote:

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

ok.

In D49489#1135667, @ziaee wrote:

@michaelo, src/tools/tools/git/git-arc.sh will do this for you. Use git arc patch -c D49489. But first, Jim is a recurring contributor, let me work with him on commit messages.

In D49489#1135464, @ziaee wrote:

Following our discussion today about patch movement, @michaelo could commit this or I'd need @carlavilla or @mhorne to approve it. For me to do it, I need a better commit message. Unfortunately afaik you need to use the webapp to do this.

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.