From nobody Thu Mar 28 16:12:33 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mail-lf0-f50.google.com (mail-lf0-f50.google.com [209.85.215.50]) by lists.alpinelinux.org (Postfix) with ESMTP id EEAB45C4EEE for ; Fri, 23 Mar 2018 02:16:40 +0000 (GMT) Received: by mail-lf0-f50.google.com with SMTP id p142-v6so16091363lfd.6 for ; Thu, 22 Mar 2018 19:16:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Ovln8f2RzYI/zNBq3t2Syo/Rfo5rZM2r56Kh0XJRyPQ=; b=UtITssVHiDdkhGor9fCHdDV2QkYLZid1Uk8cC5l+eW2ZILNAxxO1UE6ch0ks5slx+t c/ErWaBhybu5Wew7nPTv8F6WYgX29yr12zzjPT8JHCN7FDkiJLjyYkFXoH1Z0NW7AaZh 32A+2Tj2/JvCLsPdwg2JK69xvrFjpAPFp1hsw02fvQLxUAlCfNLPaCuSgVz+Cwa9kVAQ JANTymfTpg0bgtVA/SSSUWK35OIj09YLtz7HXkVSiPUhZVFNA2yzF1G0bxQ6ZeAJkS7f gcsLUAGMqHviO/sUddNMMN+423zkuGww1gKmE8NU5rphgwc2G6Pz+Xu9gEvo83iFquyL aULw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Ovln8f2RzYI/zNBq3t2Syo/Rfo5rZM2r56Kh0XJRyPQ=; b=LYDsfwgIdKp9VVQnmkdW5GyJuIj1Wqo+qG7ObSAscpE2jZ/aMxZ4X4FCYV8m0VASJ/ uMxDLBMZo4Y+YiwjZCFIj4ZfG6/wRAaTWCSTeQoBuhqezKUjtLMdeeRETxqa9k6RHjl2 XdDjZLfJVVXKGjVckr7+Yx7bBKMttRjRCTR83/6bAzG9uLt78Zdf0RYXy1sbIDuqOCGB sQV+Em5ve1voVxVlFxFoNChInfLHAbyKQFHcHAZUO1kb/uhIxfPk6OxGw7EDengxJ6Rv KvkqxDQfMa5x/GAsNQeLqkpVvpqfZLfibSKbMmBuB3E+n2XyhW+HtdE6vfTaamcfw7gC j4Ug== X-Gm-Message-State: AElRT7F7ESMGugFITDbos9pbGpIvoH76QGqpQE42r0gJLa7Mbmp7h29K saK03ytL/dd8vuq6J2T3f3C2LA7QA7EyLfaDOVs= X-Google-Smtp-Source: AG47ELszenys7pmXn3O9FG5S15yiuSRx5s1kquJLjS+zRD7XrS5Ur6PS9QXx5olTQdnq0VJzfHLgl15qVe/rBrsS1zQ= X-Received: by 2002:a19:1198:: with SMTP id 24-v6mr19263410lfr.85.1521771399579; Thu, 22 Mar 2018 19:16:39 -0700 (PDT) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 From: Christine Dodrill Date: Fri, 23 Mar 2018 02:16:28 +0000 Message-ID: Subject: [alpine-devel] What is the policy for telemetry in packages in Alpine's repos? To: "alpine-devel@lists.alpinelinux.org" Content-Type: multipart/alternative; boundary="000000000000b38e7905680b0379" --000000000000b38e7905680b0379 Content-Type: text/plain; charset="UTF-8" Hello all, I just got a notification from the Caddy[1] project's GitHub page[2] that the Caddy project is indeed going ahead with their plan to implement telemetry into the server. As implemented (default on) [3] (search "telemetry"), it exposes a rather terrifying amount of data including but not limited to: - the number of vhosts you are serving - the version of Caddy - the number of TCP(/UDP?) listeners Caddy has open - the server type of Caddy (in case you compile in the DNS server option) - OS (linux, windows, etc) - Architecture (aarch64, ppc64, etc) - CPU brand name - Number of logical CPU cores - CPU AES-NI support - the number of configuration directives in the loaded configuration - how many connections are likely or not likely to be TLS-MITM-ed - its best guess if the user is running this in development or production based on what ACME servers Caddy is configured to use - the number of sites being served by Caddy - how many hits from how many unique user agents Cadey processes - the number of HTTP requests Caddy processes - the number of TLS certs Caddy manages - the number of TLS certs that Caddy manually loads from files - the number of TLS certs obtained from an ACME server - the number of TLS certs renewed from an ACME server - the number of TLS certs revoked from an ACME server - TLS client hello information [4] (this isn't implemented yet, but they obviously plan to) - TLS handshake count - TLS handshake unique error count - the number of managed TLS certs currently loaded into ram - the number of manually loaded TLS certs currently loaded into ram - the number of self-signed certs Caddy is configured to generate in ram This seems a bit much for opt-out telemetry, and made me wonder if Alpine has any policies about packages with telemetry features in general. If so, what are they? If not, I think it would be reasonable for telemetry in alpine programs to be OPT-IN (as in: the user MUST take action to enable telemetry) or patched out from programs. --- Christine Dodrill https://christine.website [1]: https://caddyserver.com/ [2]: https://github.com/mholt/caddy/pull/2079 [3]: https://github.com/mholt/caddy/pull/2079/files [4]: https://github.com/mholt/caddy/blob/52316952a575b01871224e68d4d248c0e2cdf271/caddytls/handshake.go#L103 --000000000000b38e7905680b0379 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

I just got a notification fr= om the Caddy[1] project's GitHub page[2] that the Caddy project is inde= ed going ahead with their plan to implement telemetry into the server. As i= mplemented (default on) [3] (search "telemetry"), it exposes a ra= ther terrifying amount of data including but not limited to:
    =
  • the number of vhosts you are serving
  • the version of Caddy
  • <= li>the number of TCP(/UDP?) listeners Caddy has open
  • the server typ= e of Caddy (in case you compile in the DNS server option)
  • OS (linux= , windows, etc)
  • Architecture (aarch64, ppc64, etc)
  • CPU bran= d name
  • Number of logical CPU cores
  • CPU AES-NI support
  • <= li>the number of configuration directives in the loaded configuration<= li>how many connections are likely or not likely to be TLS-MITM-ed
  • = its best guess if the user is running this in development or production bas= ed on what ACME servers Caddy is configured to use
  • the number of si= tes being served by Caddy
  • how many hits from how many unique user a= gents Cadey processes
  • the number of HTTP requests Caddy processes
  • the number of TLS certs Caddy manages
  • the number of TLS cert= s that Caddy manually loads from files
  • the number of TLS certs obta= ined from an ACME server
  • the number of TLS certs renewed from an AC= ME server
  • the number of TLS certs revoked from an ACME server
  • <= li>TLS client hello information [4] (this isn't implemented yet, but th= ey obviously plan to)
  • TLS handshake count
  • TLS handshake uni= que error count
  • the number of managed TLS certs currently loaded in= to ram
  • the number of manually loaded TLS certs currently loaded int= o ram
  • the number of self-signed certs Caddy is configured to genera= te in ram
This seems a bit much for opt-out telemetry, and ma= de me wonder if Alpine has any policies about packages with telemetry featu= res in general. If so, what are they? If not, I think it would be reasonabl= e for telemetry in alpine programs to be OPT-IN (as in: the user MUST take = action to enable telemetry) or patched out from programs.
<= br>
---

Christine Dodrill
<= br>
--000000000000b38e7905680b0379-- --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org --- From nobody Thu Mar 28 16:12:33 2024 X-Original-To: alpine-devel@lists.alpinelinux.org Received: from mx1.tetrasec.net (mx1.tetrasec.net [74.117.190.25]) by lists.alpinelinux.org (Postfix) with ESMTP id 6C3FA5C4ED8 for ; Fri, 30 Mar 2018 08:26:00 +0000 (GMT) Received: from mx1.tetrasec.net (mail.local [127.0.0.1]) by mx1.tetrasec.net (Postfix) with ESMTP id D7FEE9E2EBD; Fri, 30 Mar 2018 08:25:59 +0000 (GMT) Received: from ncopa-desktop.copa.dup.pw (67.63.200.37.customer.cdi.no [37.200.63.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mx1.tetrasec.net (Postfix) with ESMTPSA id 0B2129E2199; Fri, 30 Mar 2018 08:25:58 +0000 (GMT) Date: Fri, 30 Mar 2018 10:25:53 +0200 From: Natanael Copa To: Christine Dodrill Cc: "alpine-devel@lists.alpinelinux.org" Subject: Re: [alpine-devel] What is the policy for telemetry in packages in Alpine's repos? Message-ID: <20180330102553.6f89763c@ncopa-desktop.copa.dup.pw> In-Reply-To: References: X-Mailer: Claws Mail 3.15.1-dirty (GTK+ 2.24.31; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Fri, 23 Mar 2018 02:16:28 +0000 Christine Dodrill wrote: > Hello all, > > I just got a notification from the Caddy[1] project's GitHub page[2] that > the Caddy project is indeed going ahead with their plan to implement > telemetry into the server. As implemented (default on) [3] (search > "telemetry"), it exposes a rather terrifying amount of data including but > not limited to: > > - the number of vhosts you are serving > - the version of Caddy > - the number of TCP(/UDP?) listeners Caddy has open > - the server type of Caddy (in case you compile in the DNS server option) > - OS (linux, windows, etc) > - Architecture (aarch64, ppc64, etc) > - CPU brand name > - Number of logical CPU cores > - CPU AES-NI support > - the number of configuration directives in the loaded configuration > - how many connections are likely or not likely to be TLS-MITM-ed > - its best guess if the user is running this in development or > production based on what ACME servers Caddy is configured to use > - the number of sites being served by Caddy > - how many hits from how many unique user agents Cadey processes > - the number of HTTP requests Caddy processes > - the number of TLS certs Caddy manages > - the number of TLS certs that Caddy manually loads from files > - the number of TLS certs obtained from an ACME server > - the number of TLS certs renewed from an ACME server > - the number of TLS certs revoked from an ACME server > - TLS client hello information [4] (this isn't implemented yet, but they > obviously plan to) > - TLS handshake count > - TLS handshake unique error count > - the number of managed TLS certs currently loaded into ram > - the number of manually loaded TLS certs currently loaded into ram > - the number of self-signed certs Caddy is configured to generate in ram > > This seems a bit much for opt-out telemetry, and made me wonder if Alpine > has any policies about packages with telemetry features in general. If so, > what are they? If not, I think it would be reasonable for telemetry in > alpine programs to be OPT-IN (as in: the user MUST take action to enable > telemetry) or patched out from programs. We don't have any written policies about this, but I would prefer that this kind of thing is an opt-in, and I would be be ok to apply an Alpine specific patch to disable telemetry by default. -nc > > --- > > Christine Dodrill > https://christine.website > > [1]: https://caddyserver.com/ > [2]: https://github.com/mholt/caddy/pull/2079 > [3]: https://github.com/mholt/caddy/pull/2079/files > [4]: > https://github.com/mholt/caddy/blob/52316952a575b01871224e68d4d248c0e2cdf271/caddytls/handshake.go#L103 --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---