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
Attachment:
signature.asc
Description: OpenPGP digital signature
