sslutil: reference appropriate config section in messaging Error messages reference the config section defining the host fingerprint. Now that we have multiple sections where this config setting could live, we need to point the user at the appropriate one. We default to the new "hostsecurity" section. But we will still refer them to the "hostfingerprint" section if a value is defined there. There are some corner cases where the messaging might be off. e.g. they could define a SHA-1 fingerprint in both sections. IMO the messaging needs a massive overhaul. I plan to do this as part of future refactoring to security settings.

sslutil: allow fingerprints to be specified in [hostsecurity] We introduce the [hostsecurity] config section. It holds per-host security settings. Currently, the section only contains a "fingerprints" option, which behaves like [hostfingerprints] but supports specifying the hashing algorithm. There is still some follow-up work, such as changing some error messages.

debuginstall: expose modulepolicy With this, you can check for pure easily: $ HGMODULEPOLICY=py ./hg debuginstall -T "{hgmodulepolicy}" py

revset: define table of sort() key functions This should be more readable than big "if" branch.

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().

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.