Bug 226048 - ports-mgmt/pkg: "pkg check --recompute" fails to exclude removed files
Summary: ports-mgmt/pkg: "pkg check --recompute" fails to exclude removed files
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Many People
Assignee: freebsd-pkg (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-19 17:01 UTC by Rafal Lukawiecki
Modified: 2022-11-19 23:15 UTC (History)
2 users (show)

See Also:
bugzilla: maintainer-feedback? (pkg)


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rafal Lukawiecki 2018-02-19 17:01:11 UTC
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.
Comment 1 Baptiste Daroussin freebsd_committer freebsd_triage 2021-08-18 08:29:22 UTC
pkg is not supposed to understand manual removal, this defeats the purpose of having packages, either this should be done via rebuild of the package or we could have some exclusion lists natively handled by pkg (which is plan in the TODO of pkg.)
Comment 2 Robert William Vesterman 2022-11-19 23:15:39 UTC
(In reply to Baptiste Daroussin from comment #1)

I just ran into this exact same issue (same files, same reason for manually removing them, and everything), and I'm afraid I don't understand the reason that this behavior is "intended".

I get that by default it should point out files that have been deleted. But the whole point of "pkg check -r" is to say "I meant to do that" when such a file is intentionally changed. Why should intentional deletion be any different?