From: "brian m. carlson" <sandals@crustytoothpaste.net>
To: Jeff King <peff@peff.net>
Cc: Christian Couder <christian.couder@gmail.com>,
Dragan Simic <dsimic@manjaro.org>,
git@vger.kernel.org, Junio C Hamano <gitster@pobox.com>,
Patrick Steinhardt <ps@pks.im>, John Cai <johncai86@gmail.com>,
Johannes Schindelin <Johannes.Schindelin@gmx.de>
Subject: Re: [PATCH 0/3] Advertise OS version
Date: Wed, 19 Jun 2024 22:46:13 +0000 [thread overview]
Message-ID: <ZnNftSO13KlmFbQ3@tapette.crustytoothpaste.net> (raw)
In-Reply-To: <20240619145042.GA957055@coredump.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 3027 bytes --]
On 2024-06-19 at 14:50:42, Jeff King wrote:
> On Wed, Jun 19, 2024 at 04:01:57PM +0200, Christian Couder wrote:
>
> > One possibility is to send just the `sysname`, described as 'Operating
> > system name (e.g., "Linux")', field of the struct utsname filled out
> > by uname(2) by default.
>
> That would be better to me. I still don't love it, but I admit it's
> coming more from a knee-jerk response than from some rational argument
> against people knowing I run Linux.
>
> Since HTTP user-agent fields are common, we can look at those for prior
> art. curl sends its own version but nothing else. Most browsers do seem
> to include some OS information. My version of firefox gives its own
> version along with "Linux x86_64". So basically "uname -sm".
If we choose to enable this, this is the right level of detail, yeah.
We could also allow a distributor to set this value at compile time,
much like Debian does for Postfix and OpenSSH. For Postfix, it's simply
"(Debian)", which doesn't give much information.
To me as a server administrator interested in statistics, it's useful to
me to know OS name and version (as in, how many users are still using an
ancient version of CentOS?), since that tells me about things like
supported TLS versions which is helpful, but as a user I don't think
that's an appropriate level of detail to share. And I also worry about
fingerprinting and tracking, which is a giant problem with HTTP
user-agents. This is especially true if you're using something like
FreeBSD RISC-V, which is just not that common.
> > And then there might be a knob to deactivate it completely or to make
> > it more verbose (which might be useful for example in a corporate
> > context).
>
> Yes, I think we should definitely have an option to suppress or override
> it, just like we do for the user-agent string.
I definitely think we should have both. I'm sure we'll have some server
maintainer or repository administrator who tries to reject "bad" OSes
(like someone who doesn't like their employees using WSL, for example).
We've already had people propose to reject access based on the version
number in the name of "security", despite the fact that most Linux
distros just backport security patches and thus the version number is
not usually interesting in that regard. Again, HTTP user-agents tell us
that people will make access control decisions here even though they
should not.
We'll want to honour people's decisions to remain a mystery or to work
around broken server implementations, or just to make it harder to track
or fingerprint them.
I also think the documentation should state that for the user-agent and
os-version fields that they are merely informative, can be changed, and
MUST NOT be used for access control. That doesn't mean people will
honour it, but it does mean that we can and should feel free to break
implementations that don't comply.
--
brian m. carlson (they/them or he/him)
Toronto, Ontario, CA
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 262 bytes --]
next prev parent reply other threads:[~2024-06-19 22:46 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-06-19 12:57 [PATCH 0/3] Advertise OS version Christian Couder
2024-06-19 12:57 ` [PATCH 1/3] version: refactor strbuf_sanitize() Christian Couder
2024-06-19 18:40 ` Eric Sunshine
2024-06-19 12:57 ` [PATCH 2/3] version: refactor get_uname_info() Christian Couder
2024-06-19 12:57 ` [PATCH 3/3] connect: advertise OS version Christian Couder
2024-06-19 13:18 ` [PATCH 0/3] Advertise " Dragan Simic
2024-06-19 13:45 ` Jeff King
2024-06-19 13:50 ` Dragan Simic
2024-06-19 14:01 ` Christian Couder
2024-06-19 14:19 ` Dragan Simic
2024-06-19 14:41 ` rsbecker
2024-06-19 14:52 ` Jeff King
2024-06-19 14:57 ` rsbecker
2024-06-19 15:53 ` Dragan Simic
2024-06-19 14:50 ` Jeff King
2024-06-19 15:25 ` rsbecker
2024-06-19 22:46 ` brian m. carlson [this message]
2024-06-20 15:25 ` Jeff King
2024-06-20 16:28 ` Junio C Hamano
2024-12-09 16:14 ` Usman Akinyemi
2024-12-09 16:34 ` rsbecker
2024-12-10 18:51 ` Usman Akinyemi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZnNftSO13KlmFbQ3@tapette.crustytoothpaste.net \
--to=sandals@crustytoothpaste.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=christian.couder@gmail.com \
--cc=dsimic@manjaro.org \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=johncai86@gmail.com \
--cc=peff@peff.net \
--cc=ps@pks.im \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).