[PATCH] url: add distribution and version to user-agent request header (BC)

[timeless]

If you're going to include things, might I suggest including the python version?

Something so that you can count pypy, cpy, py3, py2.6/py2.7, ironpy...

On Thu, Jul 14, 2016 at 9:24 PM, Pierre-Yves David
<pierre-yves.david at ens-lyon.org> wrote:
>
>
> On 07/15/2016 12:16 AM, Matt Mackall wrote:
>> On Thu, 2016-07-14 at 11:22 -0700, Gregory Szorc wrote:
>>> On Thu, Jul 14, 2016 at 11:06 AM, Augie Fackler <raf at durin42.com> wrote:
>>>
>>>>
>>>> (+mpm for history confirmation)
>>>>
>>>> On Thu, Jul 14, 2016 at 2:04 PM, Gregory Szorc <gregory.szorc at gmail.com>
>>>> wrote:
>>>>>
>>>>> On Thu, Jul 14, 2016 at 10:48 AM, Augie Fackler <raf at durin42.com> wrote:
>>>>>>
>>>>>>
>>>>>> On Wed, Jul 13, 2016 at 10:18:26PM -0700, Gregory Szorc wrote:
>>>>>>>
>>>>>>> # HG changeset patch
>>>>>>> # User Gregory Szorc <gregory.szorc at gmail.com>
>>>>>>> # Date 1468473406 25200
>>>>>>> #      Wed Jul 13 22:16:46 2016 -0700
>>>>>>> # Node ID 6ad61d5001b1fbfebf317d0557f158d4b34a0772
>>>>>>> # Parent  52433f89f816e21ca992ac8c4a41cba0345f1b73
>>>>>>> url: add distribution and version to user-agent request header (BC)
>>>>>> It's actually intentional that we don't advertise hg version in either
>>>>>> direction to my recollection.
>>>>>
>>>>> Do you know why?
>>>> I believe it's so clients don't advertise "I'm vulnerable to X!",
>>>
>>> Browsers, Git, curl, wget, and nearly every other application advertises
>>> version numbers and therefore vulnerabilities to known issues.
>>
>> Yeah, this is actually a bigger issue in the other direction. The _server_
>> should not expose its version because it's a sitting target that's vulnerable to
>> scanning. But our capabilities model makes us somewhat vulnerable to
>> fingerprinting that can establish ranges. Mostly not a problem: our server
>> attack surface for unauthenticated users is pretty solid.
>>
>>>
>>>>
>>>> and
>>>> also a bit so that people properly use capabilities and not version
>>>> numbers to sniff for behavior.
>>>>
>>> I sympathize. To counter that point, the User-Agent can also be used by
>>> servers to work around bugs in known busted clients. This is explicitly
>>> called out as a use case for the header in the HTTP RFCs.
>>
>> Yes, but the web's protocol model is not really the same as ours. In Mercurial,
>> the client is supposed to make every protocol decision while the server
>> passively does what it's asked to do while keeping no state and making no
>> choices. There's no negotiation taking place, so the server never needs or
>> should know what the client is capable of except via what it asks for.
>>
>> This model has served us very well for keeping the server side simple and
>> compatible and the client complexity has been pretty well-contained as well. But
>> it does have the various downsides you've mentioned like being unable to herd
>> your kittens remotely.
>>
>> I'm ok with exposing a version to servers for logging purposes, but we shouldn't
>> do anything to facilitate looking at it in the server side code.
>
> I'm leaning the same way, helping people to get state on their clients
> seems like a good idea, but we should  make sure there is enough ward
> around this that people stick on capability for all logic related code.
>
>> I think your theory that __version__ won't contain spaces is optimistic.
>
> Yep, we probably want to urlencode this.
>
> --
> Pierre-Yves David
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel