[arch-general] Why bind-tools was merged into bind package?

[brent s.]

Responses inline.


On 7/20/20 03:15, Óscar García Amor via arch-general wrote:
(SNIP)
> 
> 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[0]. 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[1].

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[2] 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
decisions.

>  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.
> 
> Greetings.
> 

See again the Arch Way[5]. 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.


[0] https://gitlab.isc.org/isc-projects/bind9
[1] https://wiki.archlinux.org/index.php/Arch_Linux#Simplicity
[2] https://www.archlinux.org/packages/core/x86_64/ldns/
[3a] https://www.dnspython.org/
[3b] https://www.archlinux.org/packages/community/any/python-dnspython/
[4a]
https://git.archlinux.org/svntogit/packages.git/tree/trunk/PKGBUILD?h=packages/bind
[4b]
https://wiki.archlinux.org/index.php/Pacman/Tips_and_tricks#Custom_local_repository
[5] https://wiki.archlinux.org/index.php/Arch_Linux#User_centrality

-- 
brent saner
https://square-r00t.net/
GPG info: https://square-r00t.net/gpg-info

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 899 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20200720/f1df86f4/attachment.sig>