ntpclient names

[Royce Williams]

On Wed, Feb 22, 2017 at 12:17 PM, Gary E. Miller <gem at rellim.com> wrote:
> Yo Royce!
>
> On Wed, 22 Feb 2017 11:38:04 -0900
> Royce Williams <royce at tycho.org> wrote:
>
>> On Wed, Feb 22, 2017 at 11:30 AM, Gary E. Miller <gem at rellim.com>
>> wrote:
>> >
>> > Yo Achim!
>> >
>> > On Wed, 22 Feb 2017 18:21:01 +0100
>> > Achim Gratz <Stromeko at 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