On Mon, 08 Jan 2024 10:30:02 +0100 Simon Josefsson <si...@josefsson.org> wrote:
> Josh Triplett <j...@joshtriplett.org> 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.

Reply via email to