Turns out the upgrade to php80 probably increased strictness of 0 == null, revealing a flaw in the AutoNumberField implementation. Easy fix is to never start at 0 unless explicitly set, in which case it's not an issue.
Since PHP80 decided to turn certain notices into warnings, a way to silence these is necessary, which also presents us with the opportunity to make this configurable.
as the previous version already build files in /var/db/aliastables and therefor future cleanup work, there might be some noise when patching this without a reboot (empty bogons or other external aliases). Without this patch the issue is only that aliases aren't removed, which doesn't make this a super high priority in my humble opinion.
o Since our filterlog does contain labels nowaydays (https://github.com/opnsense/core/issues/5014), we can stop parsing pfctl which can be quite time consuming
o Rate limit "filter rule stats" configd action to prevent excessive pfctl access on filter pages
o cache getservbyname() results when validating a port in isPort() and use the same static object in is_port() for legacy code
o move isAlias() to use getByName() in the alias model so we can add a simple caching mechanism there
To invalidate the cache for isAlias() one could either hook a new instance of the model using attachAliasObject() or attach an empty one attachAliasObject(null).
Since php-openssl still has no implementation for CRLs, phpseclib is now used to provide this.
To test this commit:
- Create a CA
- Create a certificate signed by the CA
- Create a CRL and revoke the above certificate
openssl verify -crl_check_all -CRLfile <crl>.crl -CAfile <ca>.crt <certificate>.crt
While here remove a couple of references from loops and
improve coding style while at it.
While openvpn_prepare() is not the same as reconfiguring
a device (pluginctl -d ovpns1 vs. pluginctl -s openvpn 1)
we can get away with it as used before. It might be the
subject of later work but for the sake of clearing the
scope of interfaces_configure() this is more than enough.
Even though the server responds with proper cache headers to avoid
browser caching, it seems that Safari (and maybe others) may still cache
repeated calls to `/api/core/firmware/upgradestatus`. This change adds
in the time-old tradition of appending the current timestamp in
milliseconds to each request which should force the browser to fetch the
resource.
Ref: https://www.reddit.com/r/opnsense/comments/umhx04/opnsense_2217_released/i83bp36/?context=5
