timeless <timeless@mozdev.org> [Wed, 09 Mar 2016 19:55:45 +0000] rev 29266
debuginstall: expose modulepolicy
With this, you can check for pure easily:
$ HGMODULEPOLICY=py ./hg debuginstall -T "{hgmodulepolicy}"
py
Yuya Nishihara <yuya@tcha.org> [Sat, 14 May 2016 19:52:00 +0900] rev 29265
revset: define table of sort() key functions
This should be more readable than big "if" branch.
Yuya Nishihara <yuya@tcha.org> [Sat, 14 May 2016 19:46:18 +0900] rev 29264
revset: factor out reverse flag of sort() key
Prepares for making a table of sort keys. This assumes 'k' has at least one
character, which should be guaranteed by keys.split().
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 May 2016 12:29:59 -0700] rev 29263
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 May 2016 11:58:28 -0700] rev 29262
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 May 2016 12:57:28 -0700] rev 29261
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 May 2016 12:53:33 -0700] rev 29260
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 May 2016 11:41:21 -0700] rev 29259
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.
Gregory Szorc <gregory.szorc@gmail.com> [Sat, 28 May 2016 11:12:02 -0700] rev 29258
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.
Danek Duvall <danek.duvall@oracle.com> [Fri, 27 May 2016 15:20:03 -0700] rev 29257
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.
Danek Duvall <danek.duvall@oracle.com> [Fri, 27 May 2016 15:10:38 -0700] rev 29256
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.
Danek Duvall <danek.duvall@oracle.com> [Fri, 27 May 2016 11:14:29 -0700] rev 29255
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.
Javi Merino <merino.jav@gmail.com> [Fri, 27 May 2016 21:24:05 +0200] rev 29254
lazymanifest: fix typo s/typles/tuples/
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 25 May 2016 19:57:31 -0700] rev 29253
sslutil: remove sslkwargs() (API)
It is now unused.
Gregory Szorc <gregory.szorc@gmail.com> [Wed, 25 May 2016 19:57:02 -0700] rev 29252
url: remove use of sslkwargs