Several of the local includes are quite obviously used in script, such as crypto. NAK as-is.

Automatic sanity-testing: PASSED, see http://jenkins.bluematt.me/pull-tester/p4674_54f048158b1b9864b5119c5f7dc3f126182288c0/ for binaries and test log.
This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

Those are included in hash, which is included in key, which is included in keystore.
Otherwise the build would fail, no?

You always want to include all direct dependencies of a file. Doing so
makes it 1) clear which code you're depending on and 2) makes the codebase
robust against refactoring (for example, A depends on B, A and B both
depend on C; B is changed to no longer need C... if A didn't include C
directly, this would cause build failures).

As a general rule, an indirect dependency should not hide a direct
dependency. There is one exception: if A.cpp and A.h both depend on B, it
is omitted in the .cpp file (the .cpp and .h file are considered one unit).

Using an #include says "I am using this API" It does not matter if other headers also use that API; you cannot depend on that fact, as indirect dependencies may change.

This change makes the build more fragile and misunderstands how standard C/C++ header inclusion works.