Why are dnssec-{keygen,signzone} in /usr/sbin?  They are perfectly usable
from normal user accounts and zone signing actions are not exactly carried
through by "system binaries" as specified by the FHS.

Control: tags -1 +patch

Find attached a patch to handle this and other similar cases (rndc and friends).

There are many tools which can be used by non-root users with no problems.

The package builds fine with the patch but please, review the patch
before applying it, since my knowedge of the this complex bind9 source
package is limited.
I based the patch on the last commit on master [0], but should
probably apply on top of other commits/branches.

The patch should probably be forwarded upstream.

[0] https://anonscm.debian.org/git/pkg-bind/pkg-bind.git/commit/?id=e6f63f5a85d8fe6f22a995787e806f4887df9689

On Sun, Aug 22, 2010 at 03:41:49PM +0200, Philipp Kern wrote:

Hi,

This is where upstream (and every other distribution) puts these files.
Changing this now would break compatibity with everyone else and
existing scripts referencing the full path name.

Nothing prevents you from calling these programs with the full path (or
changing PATH in your script).

Bernhard

Hi all--

I don't think this is a good resolution for #593940, and i hope we can
revert it.

By this argument, we would never fix any upstream bugs at all :)  Debian
has the opportunity to lead the way here.

Debian policy §6.1 (about maintainer scripts) says:

    Programs called from maintainer scripts should not normally have a
    path prepended to them. Before installation is started, the package
    management system checks to see if the programs ldconfig,
    start-stop-daemon, and update-rc.d can be found via the PATH
    environment variable. Those programs, and any other program that one
    would expect to be in the PATH, should thus be invoked without an
    absolute pathname. Maintainer scripts should also not reset the
    PATH, though they might choose to modify it by prepending or
    appending package-specific directories. These considerations really
    apply to all shell scripts.

Note the last sentence ;)

Yes, people do put the full path in their scripts, which makes them
brittle and unfortunate.  Why do people put the full path in their
scripts?  Often it's because the tools they want to use aren't shipped
already in the $PATH.  For example, the useful tools in bind9utils.

So actually fixing this bug would lead to less brittle systems in the
future, which is a good thing.

If we want to continue supporting things that have embedded the full
path, we can ship symlinks in /usr/sbin/ that point back to /usr/bin.

If we shipped these backward-compatibility symlinks, would that be
acceptable to address your concerns?

I think that best course of action would be to wait till January and
fill an upstream issue in an upstream gitlab for BIND ;)

I think this is reasonable, but what about we change this in an upstream
first and then backport the change?

O.

On 14.12.2017 09:34, Ondřej Surý wrote:

Hi everyone,

I agree. Even with compatibility symlinks, I fear people will be using
/usr/bin/dnssec-* directly, breaking compatibility with other
distributions and upstream. Too much pain for the gain, if it needs to
be carried permanently.

However, if upstream is sympathetic to this and will eventually arrive
there, I have absolutely no objection to backport this. Or if anyone
else in the team wants to push this through.

Bernhard

Control: forwarded 593940 https://bugs.isc.org/Public/Bug/Display.html?id=46949

i don't see any gitlab for BIND, but i do see the RT instance over at
https://bugs.isc.org/Public/Dist/Display.html?Name=bind9-public.

given that it's january, i've gone ahead and filed a bug report
upstream (it doesn't seem to be visible to the public yet):

https://bugs.isc.org/Public/Bug/Display.html?id=46949

On Wed, Jan 03, 2018 at 02:35:18PM -0500, Daniel Kahn Gillmor wrote:

Hi,

It's still not public, and I think the migration to the Gitlab tracker
is a manual process.

Would you mind filing it again at
https://gitlab.isc.org/isc-projects/bind9/issues ?

Thanks,
Bernhard

This has been fixed in upstream now.

Ondrej
--
Ondřej Surý (He/Him)
ondrej@sury.org