In D16857#524898, @kevans wrote:

In D16857#524890, @1983-01-06_gmx.net wrote:

That all looks fine.

Here are now my questions:

1. Why has the hash option selected? D16352 uses the common approach to concat PEM files into one PEM bundle which can be easily transported and distributed.

I wasn't initially involved in this decision, but I find it more convenient to manually manage or identify what's being trusted as-is, since I can ls/grep around /etc/ssl/certs.

In D16857#524909, @1983-01-06_gmx.net wrote:

As far as I can see when certs in are in base security/ca_root_nss seems to be obsolete for me, these ports need to be changed:

In D9920#308104, @rgrimes wrote:

This patch leaves that value alone, that value is 1 by default. The added rules shall reassemble all UDP packets, and since one_pass is set it well at that point PASS THE PACKET. This is a huge hole in the firewall in effect allowing all UDP traffic to pass inward without any port or state being checked. With the added rule that reassembles udp packets it is a MUST that net.inet.ip.fw.one_pass be set to 0 so that the additional checks later in the firewall can be checked. It is also a must that the rule be moved before the check-state.

In D9920#307830, @rgrimes wrote:

The reass rule has the side effect that once it assmebles a packet if net.net.ip.fw.one_pass=0 it passes
the packet without any further processing. That is not the desired behavior of a firewall.

Running a reass rule without net.net.ip.fw.one_pass=0 results in a firewall that can be
circumvented by simply fragmenting all packets.

In D9920#307797, @rgrimes wrote:

I am not so sure if we want to turn on net.inet.ip.fw.one_pass

Please put the reass before the check-state as fragments (except the first) don't carry protocol and port and thus cannot be dealt with by check-state anyhow. This will save a few cycles.