Re: [RFC PATCH v1] telemetry design overview (part 1)

From: brian m. carlson <sandals@crustytoothpaste.net>
Date: Jun 10, 2018, 00:00 UTC
Message-ID: <20180610000056.GD38834@genre.crustytoothpaste.net>
In-Reply-To: <900a34bb-4d8b-4a22-a0f5-1d2f6df84945@kdbg.org>

On Sat, Jun 09, 2018 at 08:56:00AM +0200, Johannes Sixt wrote:

Show 34 quoted lines

> Am 09.06.2018 um 00:20 schrieb Ævar Arnfjörð Bjarmason:
> > 
> > On Fri, Jun 08 2018, Johannes Sixt wrote:
> > Can you elaborate on how someone who can maintain inject malicious code
> > into your git package + config would be thwarted by this being some
> > compile-time option, wouldn't they just compile it in?
> 
> Of course they can. But would we, the Git community do that?
> 
> From the design document:
> 
> > The goal of the telemetry feature is to be able to gather usage data
> > across a group of production users to identify real-world performance
> > problems in production.  Additionally, it might help identify common
> > user errors and guide future user training.
> 
> The goal to gather usage data may be valid for a small subset of Git
> installations. But it is wrong to put this into the software itself, in
> particular when the implementations includes scary things like loading
> unspecified dynamic libraries:
> 
> > If the config setting "telemetry.plugin" contains the pathname to a
> > shared library, the library will be dynamically loaded during start up
> > and events will be sent to it using the plugin API.
> 
> When you want usage data, ask your users for feedback. Look over their
> shoulders. But do not ask the software itself to gather usage data. It will
> be abused.
> 
> Do not offer open source software that has a "call-home" method built-in.
> 
> If you want to peek into the workplaces of YOUR users, then monkey-patch
> survaillance into YOUR version of Git. But please do not burden the rest of
> us.

I understand there's an interest in supporting the most people with the fewest amount of staff. I'm certainly in the situation where I, with only minimal assistance, support every Git user in my division of the company, regardless of technical ability, and I know how overwhelming that can be. (Burnout, I can tell you, is a thing.)

I also have to look at this issue from the interests of what is best for the FLOSS community and for users as a whole. Adding in functionality that sends off usage data from a command-line tool, especially one that is as widely used as Git is, is not in the interests of users as a whole, nor is it common practice in FLOSS tools.

As a highly capable and technical user, I would find it very undesirable to have my development tools reporting data like this, even if it is to make my experience better.

The ability to load arbitrary libraries makes me concerned about people using this to spirit away personal or company data or to subtly steal data in a rootkit-like situation. These are real threats in the kinds of environments I distribute to in my work role.

I agree with Duy's point of view that GIT_TRACE-level output to a file descriptor or file is fine, but a persistently enabled feature is not.

I expect this feature, if implemented, would be patched out of Debian's Git, and it would be patched out of any Git I would distribute in my work role for legal and ethical reasons.

As developers, we have a duty to be mindful of how our software can be misused and abused and try to avoid that when possible. I don't think this feature is on the right side of that balance.

-- 
brian m. carlson: Houston, Texas, US
OpenPGP: https://keybase.io/bk2204