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

Matt Mackall mpm at selenic.com
Thu Jul 14 18:16:12 EDT 2016


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 think your theory that __version__ won't contain spaces is optimistic.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list