Re: [PATCH 2 of 2] chg: change server's process title

[Pierre-Yves David]

On 01/11/2017 02:13 AM, Jun Wu wrote:

# HG changeset patch
# User Jun Wu 
# Date 1484091652 -28800
#  Wed Jan 11 07:40:52 2017 +0800
# Node ID b68bec41a5562c8fa0ed9ac0e94f0c2d6906a2e8
# Parent  a82e9f172feff7ca2380b3db8833ddc64cd35429
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft -r b68bec41a556
chg: change server's process title


Seems reasonable, these two are pushed

Cheers,

--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 7 of 8] chg: remove getpager support

[Pierre-Yves David]

On 01/11/2017 04:40 AM, Jun Wu wrote:

Excerpts from Pierre-Yves David's message of 2017-01-10 18:22:39 +0100:


On 01/10/2017 03:45 PM, Yuya Nishihara wrote:

On Tue, 10 Jan 2017 07:12:27 +0800, Jun Wu wrote:

# HG changeset patch
# User Jun Wu 
# Date 1484002779 -28800
#  Tue Jan 10 06:59:39 2017 +0800
# Node ID 24c7b11cecd12762d8238ec96c748131877054be
# Parent  e44b1d6deadb67908b43909ad920572e3efa38e6
# Available At https://bitbucket.org/quark-zju/hg-draft
#  hg pull https://bitbucket.org/quark-zju/hg-draft  -r 24c7b11cecd1
chg: remove getpager support

We have enough bits to switch to the new chg pager code path in runcommand.
So just remove the legacy getpager support.

This is a red-only patch, and will break chg's pager support temporarily.


I love red patches. Queued the series, thanks!


Hooray for removing much code!
I'm curious about the breakage however. It is not too important because
chg is experimental but is that breakage fixed by the next changeset?
could have reordered or folded this patch to avoid being temporarily broken?


If Patch 7 and Patch 8 were folded, there would be no breakage.

They are separated to comply with the small commit workflow.


For the record, I put the "no breakage between commit" principle before 
the "small commit submission" one (and we can usually adapt the slicing 
of commit to keep both).


(But, that's not too important in this case so I've accepted these patch 
yesterday anyway)


--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Re: [PATCH 3 of 3] hgweb: use archivespecs for links on repo index page too

[Pierre-Yves David]

On 01/11/2017 03:53 AM, Anton Shestakov wrote:

# HG changeset patch
# User Anton Shestakov 
# Date 1484062918 -28800
#  Tue Jan 10 23:41:58 2017 +0800
# Node ID e0ed84e1828ad1763c2a0e9ba4e66cf35847cf6f
# Parent  371a1ab6cf5054605d63ba497153115f2117ef10
hgweb: use archivespecs for links on repo index page too

Moving archivespecs to the module level allows using it from other modules
(such as hgwebdir_mod), and keeping a reference to it in requestcontext allows
current code to just work.


These are pushed, thanks.

Cheers,

--
Pierre-Yves David
___
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

[PATCH] hgweb: support Content Security Policy

[Gregory Szorc]

# HG changeset patch
# User Gregory Szorc 
# Date 1484120228 28800
#  Tue Jan 10 23:37:08 2017 -0800
# Node ID 113293954736e020d29e8e48aa3e01657ec853f3
# Parent  79314c9a79b3aa033b6f79d066b97d7157ecac33
hgweb: support Content Security Policy

Content-Security-Policy (CSP) is a web security feature that allows
servers to declare what loaded content is allowed to do. For example,
a policy can prevent loading of images, JavaScript, CSS, etc unless
the source of that content is whitelisted (by hostname, URI scheme,
hashes of content, etc). It's a nifty security feature that provides
extra mitigation against some attacks, notably XSS.

Mitigation against these attacks is important for Mercurial because
hgweb renders repository data, which is commonly untrusted. While we
make attempts to escape things, etc, there's the possibility that
malicious data could be injected into the site content. If this happens
today, the full power of the web browser is available to that
malicious content. A restrictive CSP policy (defined by the server
operator and sent in an HTTP header which is outside the control of
malicious content), could restrict browser capabilities and mitigate
security problems posed by malicious data.

CSP works by emitting an HTTP header declaring the policy that browsers
should apply. Ideally, this header would be emitted by a layer above
Mercurial (likely the HTTP server doing the WSGI "proxying"). This
works for some CSP policies, but not all.

For example, policies to allow inline JavaScript may require setting
a "nonce" attribute on . This attribute value must be unique
and non-guessable. And, the value must be present in the HTTP header
and the HTML body. This means that coordinating the value between
Mercurial and another HTTP server could be difficult: it is much
easier to generate and emit the nonce in a central location.

This commit introduces support for emitting a
Content-Security-Policy header from hgweb. A config option defines
the header value. If present, the header is emitted. A special
"%nonce%" syntax in the value triggers generation of a nonce and
inclusion in