Martin von Zweigbergk <martinvonz@google.com> [Tue, 11 Jul 2017 10:46:35 -0700] rev 33496
sparse: override dirstate.walk() instead of dirstate._ignore
Instead of treating files that are outside the sparse config as
ignored, this makes it so we list only those that are within the
sparse config by passing the sparse matcher to dirstate.walk().
Once we add support for narrow (sparseness applied to history, not
just working copy), we will need to do a similar restriction of the
walk over manifests, so this will be more consistent then. It also
simplifies the code a bit.
Note that a side-effect of this change is that files outside the
sparse config used to be listed as ignored, but they will now not be
listed at all. This can be seen in the test case where "hg purge" no
longer has any effect because it doesn't see that the files outside
the space config exist. To fix that, I think we should add an option
to dirstate.walk() to walk outside the sparse config. We might expose
that to the user as --no-sparse flag to e.g. "hg status" and "hg
purge", but that's work for another day.
Differential Revision: https://phab.mercurial-scm.org/D59
Jun Wu <quark@fb.com> [Wed, 12 Jul 2017 15:24:47 -0700] rev 33495
patch: use devel.all-warnings to replace devel.all
It appears to be a misspell in patch.py.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 12 Jul 2017 18:37:13 -0400] rev 33494
sslutil: inform the user about how to fix an incomplete certificate chain
This is a Windows only thing. Unfortunately, the socket is closed at this point
(so the certificate is unavailable to check the chain). That means it's printed
out when verification fails as a guess, on the assumption that 1) most of the
time verification won't fail, and 2) sites using expired or certs that are too
new will be rare. Maybe this is an argument for adding more functionality to
debugssl, to test for problems and print certificate info. Or maybe it's an
argument for bundling certificates with the Windows builds. That idea was set
aside when the enhanced SSL code went in last summer, and it looks like there
were issues with using certifi on Windows anyway[1].
This was tested by deleting the certificate out of certmgr.msc > "Third-Party
Root Certification Authorities" > "Certificates", seeing `hg pull` fail (with
the new message), trying this command, and then successfully performing the pull
command.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2016-October/089573.html
Matt Harbison <matt_harbison@yahoo.com> [Thu, 30 Mar 2017 00:27:46 -0400] rev 33493
debug: add a method to check the state of, and built an SSL cert chain
This is only useful on Windows, and avoids the need to use Internet Explorer to
build the certificate chain. I can see this being extended in the future to
print information about the certificate(s) to help debug issues on any platform.
Maybe even perform some of the python checks listed on the secure connections
wiki page. But for now, all I need is 1) a command that can be invoked in a
setup script to ensure the certificate is installed, and 2) a command that the
user can run if/when a certificate changes in the future.
It would have been nice to leverage the sslutil library to pick up host specific
settings, but attempting to use sslutil.wrapsocket() failed the
'not sslsocket.cipher()' check in it and aborted.
The output is a little more chatty than some commands, but I've seen the update
take 10+ seconds, and this is only a debug command.
Matt Harbison <matt_harbison@yahoo.com> [Wed, 29 Mar 2017 23:45:23 -0400] rev 33492
win32: add a method to trigger the Crypto API to complete a certificate chain
I started a thread[1] on the mailing list awhile ago, but the short version is
that Windows doesn't ship with a full list of certificates[2]. Even if the
server sends the whole chain, if Windows doesn't have the appropriate
certificate pre-installed in its "Third-Party Root Certification Authorities"
store, connections mysteriously fail with:
abort: error: [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:661)
Windows expects the application to call the methods invoked here as part of the
certificate verification, triggering a call out to Windows update if necessary,
to complete the trust chain. The python bug to add this support[3] hasn't had
any recent activity, and isn't targeting py27 anyway.
The only work around that I could find (besides figuring out the certificate and
walking through the import wizard) is to browse to the site in Internet
Explorer. Opening the page with FireFox or Chrome didn't work. That's a pretty
obscure way to fix a pretty obscure problem. We go to great lengths to
demystify various SSL errors, but this case is clearly lacking. Let's try to
make things easier to diagnose and fix.
When I had trouble figuring out how to get ctypes to work with all of the API
pointers, I found that there are other python projects[4] using this API to
achieve the same thing.
[1] https://www.mercurial-scm.org/pipermail/mercurial-devel/2017-April/096501.html
[2] https://support.microsoft.com/en-us/help/931125/how-to-get-a-root-certificate-update-for-windows
[3] https://bugs.python.org/
issue20916
[4] https://github.com/nvaccess/nvda/blob/
3b86bce2066b1934df14b96f2e83369900860ecf/source/updateCheck.py#L511
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 19:40:23 +0200] rev 33491
bookmarks: use 'applychanges' for bookmark update
There is still some use of 'deletedivergent' bookmark here. They will be taken
care of later. The 'deletedivergent' code needs some rework before fitting in
the new world.
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 17:46:47 +0200] rev 33490
bookmark: use 'applychanges' in 'repair.strip'
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 17:44:25 +0200] rev 33489
bookmark: use 'applychanges' in the mq extension
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 17:37:48 +0200] rev 33488
bookmark: use 'applychanges' when stripping
Boris Feld <boris.feld@octobus.net> [Mon, 10 Jul 2017 17:30:20 +0200] rev 33487
bookmark: use 'applychanges' in the convert extension