On Wed, Feb 22, 2017 at 12:17 PM, Gary E. Miller <g...@rellim.com> wrote: > Yo Royce! > > On Wed, 22 Feb 2017 11:38:04 -0900 > Royce Williams <ro...@tycho.org> wrote: > >> On Wed, Feb 22, 2017 at 11:30 AM, Gary E. Miller <g...@rellim.com> >> wrote: >> > >> > Yo Achim! >> > >> > On Wed, 22 Feb 2017 18:21:01 +0100 >> > Achim Gratz <strom...@nexgo.de> wrote: >> > >> > > Gary E. Miller writes: >> > > > Mark was thinking of a separate ntp-tools package or option. >> > > > Many distros has a X package and a matching X-tools package. >> > > > We could make that easy with a build option. >> > > > >> > > > I see the vast majority of users only using ntpd. >> > > > >> > > > But seriously, do you really need to save USD$0.001 of disk >> > > > space? >> > > >> > > I'm pretty sure that Hal was more concerned about not putting >> > > stuff on a public-facing server that wasn't absolutely >> > > necessary. >> > >> > Then 90% of your distro is probably also not absolutely necessary. >> > >> > If your attacker can run things on your CLI then it is long past >> > game over. >> >> The attack surface isn't binary. > > Agreed 100%. Things like CLI tools with no special permissions or > capabilities are way at the bottom of the worry scale. Lost in the > noise floor.
Fair. :) >> IMO, it's better for the ecosystem to let each admin decide which >> things to install or to leave out. If it's an easy split to make, I'd >> rather that admins have the option. > > Nothing we do says an admin can't "rm /usr/bin/XXX". I often have that > in my build scripts. No need to clutter the build options for that. Bespoke downstream file removal has its place -- but there's a break-even point. IMO, it's better for projects to provide a reasonable baseline client/server split. It allows the project to express a broad, informed recommendation about where the split should occur. It also allows the project to change that split in a controlled and long-term-ecosystem-friendly manner if the need arises. In other words: if something is added to the client side, it's inefficient for X number of admins to go update their "rm /usr/bin/XXX" scripts. As soon as the value of "X" gets above just a few people, having the project advise and update the split is a superior force multiplier. Splitting client and server is also very appliance- and embedded-friendly. IMO, anything reasonable that we can do to make it easier -- even just to reduce the cognitive load on the developers -- is a technical and PR win. Royce _______________________________________________ devel mailing list devel@ntpsec.org http://lists.ntpsec.org/mailman/listinfo/devel