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

[Pierre-Yves David]

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