tests: don't save host fingerprints in hgrc Previously, the test saved the host fingerprints in hgrc. Many tests override the fingerprint at run-time. This was a bit dangerous and was too magical for my liking. It will also interfere with a future patch that adds a new source for obtaining fingerprints. So change the test to require the fingerprint on every command invocation.

sslutil: calculate host fingerprints from additional algorithms Currently, we only support defining host fingerprints with SHA-1. A future patch will introduce support for defining fingerprints using other hashing algorithms. In preparation for that, we rewrite the fingerprint verification code to support multiple fingerprints, namely SHA-256 and SHA-512 fingerprints. We still only display the SHA-1 fingerprint. We'll have to revisit this code once we support defining fingerprints with other hash functions. As part of this, I snuck in a change to use range() instead of xrange() because xrange() isn't necessary for such small values.

util: add sha256 Upcoming patches will teach host fingerprint checking to verify non-SHA1 fingerprints. Many x509 certificates these days are SHA-256. And modern browsers often display the SHA-256 fingerprint for certificates. Since SHA-256 fingerprints are highly visible and easy to obtain, we want to support them for fingerprint pinning. So add SHA-256 support to util. I did not add SHA-256 to DIGESTS and DIGESTS_BY_STRENGTH because this will advertise the algorithm on the wire protocol. I wasn't sure if that would be appropriate. I'm playing it safe by leaving it out for now.

sslutil: move CA file processing into _hostsettings() The CA file processing code has been moved from _determinecertoptions into _hostsettings(). As part of the move, the logic has been changed slightly and the "cacerts" variable has been renamed to "cafile" to match the argument used by SSLContext.load_verify_locations(). Since _determinecertoptions() no longer contains any meaningful code, it has been removed.

sslutil: move SSLContext.verify_mode value into _hostsettings _determinecertoptions() and _hostsettings() are redundant with each other. _hostsettings() is used the flexible API we want. We start the process of removing _determinecertoptions() by moving some of the logic for the verify_mode value into _hostsettings(). As part of this, _determinecertoptions() now takes a settings dict as its argument. This is technically API incompatible. But since _determinecertoptions() came into existence a few days ago as part of this release, I'm not flagging it as such.

sslutil: introduce a function for determining host-specific settings This patch marks the beginning of a series that introduces a new, more configurable, per-host security settings mechanism. Currently, we have global settings (like web.cacerts and the --insecure argument). We also have per-host settings via [hostfingerprints]. Global security settings are good for defaults, but they don't provide the amount of control often wanted. For example, an organization may want to require a particular CA is used for a particular hostname. [hostfingerprints] is nice. But it currently assumes SHA-1. Furthermore, there is no obvious place to put additional per-host settings. Subsequent patches will be introducing new mechanisms for defining security settings, some on a per-host basis. This commits starts the transition to that world by introducing the _hostsettings function. It takes a ui and hostname and returns a dict of security settings. Currently, it limits itself to returning host fingerprint info. We foreshadow the future support of non-SHA1 hashing algorithms for verifying the host fingerprint by making the "certfingerprints" key a list of tuples instead of a list of hashes. We add this dict to the hgstate property on the socket and use it during socket validation for checking fingerprints. There should be no change in behavior.

tests-subrepo-git: emit a different "pwned" message based on the test Having a single "pwned" message which may or may not be emitted during the tests for CVE-2016-3068 leads to extra confusion. Allow each test to emit a more detailed message based on what the expectations are. In both cases, we expect a version of git which has had the vulnerability plugged, as well as a version of mercurial which also knows about GIT_ALLOW_PROTOCOL. For the first test, we make sure GIT_ALLOW_PROTOCOL is unset, meaning that the ext-protocol subrepo should be ignored; if it isn't, there's either a problem with mercurial or the installed copy of git. For the second test, we explicitly allow ext-protocol subrepos, which means that the subrepo will be accessed and a message emitted confirming that this was, in fact, our intention.

tests-subrepo-git: make the "pwned" message output in a stable order The "pwned" message from this test gets gets sent to stderr, and so may get emitted in different places from run to run in the rest of mercurial's output. This patch forces the message to go to a specific file instead, whose existence and contents we can examine at a stable point in the test's execution.

test-cache-abuse: correct for different hunk headers between Solaris and GNU When diffing against an empty file, Solaris diff uses 1 to designate the first line of the empty file (either -1,0 on the left or +1,0 on the right) while GNU diff uses 0 (-0,0 and +0,0). We use a glob here to make sure the test passes with either toolchain. I've not added tests to check-code because there are scads of places in the tests where the GNU format is used due to that being the format that "hg diff" and "hg export" use, and changing those to use globs seems wrong.

lazymanifest: fix typo s/typles/tuples/

sslutil: remove sslkwargs() (API) It is now unused.

url: remove use of sslkwargs

mail: remove use of sslkwargs

httpconnection: remove use of sslkwargs It now does nothing.

sslutil: move sslkwargs logic into internal function (API) As the previous commit documented, sslkwargs() doesn't add any value since its return is treated as a black box and proxied to wrapsocket(). We formalize its uselessness by moving its logic into a new, internal function and make sslkwargs() return an empty dict. The certificate arguments that sslkwargs specified have been removed from wrapsocket() because they should no longer be set.

sslutil: remove ui from sslkwargs (API) Arguments to sslutil.wrapsocket() are partially determined by calling sslutil.sslkwargs(). This function receives a ui and a hostname and determines what settings, if any, need to be applied when the socket is wrapped. Both the ui and hostname are passed into wrapsocket(). The other arguments to wrapsocket() provided by sslkwargs() (ca_certs and cert_reqs) are not looked at or modified anywhere outside of sslutil.py. So, sslkwargs() doesn't need to exist as a separate public API called before wrapsocket(). This commit starts the process of removing external consumers of sslkwargs() by removing the "ui" key/argument from its return. All callers now pass the ui argument explicitly.

dirstate: remove file from copymap on drop As the copymap is short-lived object regenerated from dirstate on each read this didn't affect us in any serious way. But since I've started working on permanent storage of copymap in my experiments with sqldirstate[1] I've seen this bug leaving the copy information in copymap after reverting the file moves and copies. [1] https://www.mercurial-scm.org/wiki/SQLDirstatePlan

run-tests: use json.dumps(separators=) Followup to daff05dcd184 per Martijn Pieters

debugignore: make messages translatable These messages have been overlooked by check-code, because they start with non-alphabet character ('%' or '('). Making these messages translatable seems reasonable, because messages for ui.note(), ui.status(), ui.progress() and descriptive messages for ui.write() in "debug" commands are already translatable in many cases. This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

grep: make a message translatable This message has been overlooked by check-code, because it starts with non-alphabet character (' '). This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

subrepo: make a message translatable This message has been overlooked by check-code, because it starts with non-alphabet character ('%'). This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

merge: make messages translatable These messages have been overlooked by check-code, because they start with non-alphabet character (' '). Making these messages translatable seems reasonable, because all other 'ui.note()'-ed messages in calculateupdates() are already translatable. This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

httppeer: make a message translatable This message has been overlooked by check-code, because it starts with non-alphabet character ('('). Making this message translatable seems reasonable, because exception message below in same function is already translatable - 'cannot create new http repository' This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

notify: make a message translatable This message has been overlooked by check-code, because it starts with non-alphabet character ('\'). Making this message translatable seems reasonable, because messages below in same function are already translatable - '\ndiffs (truncated from %d to %d lines):\n\n' - '\ndiffs (%d lines):\n\n' This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

gpg: make a message translatable This message has been overlooked by check-code, because it starts with non-alphabet character ('%'). This is also a part of preparation for making "missing _() in ui message" detection of check-code more exact.

revset: use getargsdict for sort() This makes it possible to use keyword arguments to specify per-sort options. For example, a hypothetical 'first' option for the user sort could sort certain users first with: sort(all(), user, user.first=mpm@selenic.com)

merge with stable

changegroup: extract method that sorts nodes to send The current implementation of narrowhg needs to influence the order in which nodes are sent to the client. adgar@ and I think this is fixable, but it's going to require pretty substantial time investment, so in the interim we'd like to extract this method. I think it makes the group() code a little more obvious, as it took us a couple of tries to isolate the exact behavior we were observing.

hg: disable demandimport for py3

tests: enable import checker for all python files (including no .py files) i18n/posplit is excluded as it couldn't be trivially fixed. That's the same as 99a2bdad0fda.