[arch-general] Why bind-tools was merged into bind package?
bts at square-r00t.net
Mon Jul 20 08:34:54 UTC 2020
On 7/20/20 03:15, Óscar García Amor via arch-general wrote:
> The problem is. Where is the limit? The whole distribution in one
> package? The argument is the same, if you don't need it simply don't
> use it.
Because the binaries formerly known as "bind-tools" are a part of BIND9
proper. Upstream, by including "bind-tools" binaries in the source
for the BIND9 daemon, ipso facto *intends* them to be built (and thusly
packaged) together. To do so otherwise is - one can make the argument -
*not* The Arch Way.
Sure, split packages are a thing, but they can get messy and are a bit
more of a pain to maintain. Simplicity, being a core value of Arch,
prefers monolithic packages where reasonable and sensible. I think this
is plenty sensible. There are more tools to investigate DNS than host,
dig, nslookup. What you probably want is ldns for your specific use
cases. Alternatively, you can write your own tools -i.e. [3a][3b]) that
do and behave *exactly* as you want them to, with no extra frills which
leaves your install even more minimal than bind-tools would have.
You can also, of course, modify the PKGBUILD[4a] for bind yourself, use
it to build a split package, and then even add it to your own
repository[4b] if you feel that keeping them separate packages is
superior. You have a lot of options to make your system behave exactly
how *you* want it to without requesting Arch to change *its* design
> In this case we are talking about binaries widely used that will be
> installed with a service rarely used. I think that packages that have
> enough entity to be splitted should do it. From my point of view is
> safer don't have a service installed than installed an disabled.
See again the Arch Way. Arch promises simplicity; it does not promise
appeal to masses.
Exploiting a service that is installed but not running (as unlike many
other distros, Arch does not automatically enable/start a service upon
installation) requires access to the machine in the first place. A
vulnerability in bind's daemon, at that point, is going to be much less
a concern than the attacker actually having arbitrary execution
privileges on your box at that point in time, I'd reckon.
GPG info: https://square-r00t.net/gpg-info
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 899 bytes
Desc: OpenPGP digital signature
More information about the arch-general