On Mon, 08 Jan 2024 10:30:02 +0100 Simon Josefsson <[email protected]> wrote: > Josh Triplett <[email protected]> writes: > > Many tools that use .d configuration directories support multiple such > > directories, to make it easy to separate local sysadmin configuration > > from distribution configuration. For instance, a hypothetical > > apt-verify-myplugin package could install > > /usr/share/apt/verify.d/50myplugin so that it automatically works when > > installed, and then the sysadmin could change that with > > /etc/apt/verify.d/50myplugin . One of several advantages of this is that > > a sysadmin can, themselves, *package* their configuration very easily, > > without having to divert files or similar. > > Thanks for feedback -- this makes sense, and I've opened an upstream bug > about it: > > https://gitlab.com/debdistutils/apt-verify/-/issues/6 > > What do you think about processing identically named scripts in both > paths vs only the /etc/ script?
Replied there: Having identically named files in /etc override the ones in /usr/share is exactly what I had in mind; I should have been more explicit about that. > > (Also, in the process of this, you might consider refusing to run if no > > configuration exists, to avoid effectively disabling verification. If a > > user really wants to *disable* verification they should use the apt > > configuration for *that* rather than installing apt-verify as a hook and > > then giving apt-verify nothing to do.) > > There is no way verification can be disabled -- apt will yell. Or can > you explain more what you mean? Just dug into apt-verify's documentation more, and realized that apt is checking gpgv output rather than exit code, so this isn't actually a concern. Nevermind then. If, at some point in the future, apt adds a verification mechanism that uses exit codes rather than the output of GPG, then it'd be important to make sure that an empty .d directory or one where all the scripts have been masked by empty ones (or symlinks to /dev/null) in /etc causes a failure.
