Following installation of www/apache24 using pkg 1.10.3 on 11.1-RELEASE-p6, I removed the unnecessary "default" web site that it creates in /usr/local/www/apache24, as its presence extends the security perimeter unnecessarily, and it fulfils no useful function, not to mention interfering with the way we manage /usr/local/www.
This had the effect of throwing a lengthy, daily security run output from pkg check. Example lines:
Checking for packages with mismatched checksums:
apache24-2.4.29: missing file /usr/local/www/apache24/cgi-bin/printenv
apache24-2.4.29: missing file /usr/local/www/apache24/cgi-bin/test-cgi
apache24-2.4.29: missing file /usr/local/www/apache24/error/HTTP_BAD_GATEWAY.html.var
apache24-2.4.29: missing file /usr/local/www/apache24/error/HTTP_BAD_REQUEST.html.var
Since the absence of those files is our intended, correct state, I run "pkg check --recompute" with sufficient privileges. To my surprise, the daily security output continues.
Perhaps pkg check --recompute does not properly take care of removed files, and perhaps only focuses on the changed ones. A workaround of disabling pkg check from validating the checksums is rather extreme. Ideally, it should be possible to somehow "reset" its database to assume that a given change, even if it includes removed files, is to be considered correct from that point onwards.
FYI, although removing /usr/local/www/apache24 has been our practice for well over a year, this output from pkg check only started showing up recently, I think since 11.1-p4 or so.