I've made what I think is exciting progress on the digital signatures design for wheel (updated built/binary packages for Python; intended to replace egg). The insight is that we can overload the "extras" syntax as a convenient way to mention the public key we expect: package[extra, ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA] This line in a pip-style requires.txt specifies that we want to install package, the normal optional dependency "extra" and that we expect it to have a valid signature made with the mentioned ed25519 public key. Distribute your application, assemble its requirements in this format, sign that file, and Bob's your uncle -- your users can install from that file and know that the requirements they download have the same publishers as the packages you developed with. This is far more powerful than a file hash because it is valid for more than one version of the package. For backwards compatibility, packages can say they provide the extra ed25519=ouBJlTJJ4SJXoy8Bi1KRlewWLU6JW7HUXTgvU1YRuiA (adding no dependencies) and easy_install should parse and ignore it, installing from an unsigned egg or source distribution because it doesn't know about wheels. bdist_wheel will be updated to always sign the wheels it generates if possible, making up a new signing key if one is not stored on the building machine. That way signed wheels will be commonplace, and the remaining problem is simply to decide which signing keys you would like to trust. wheel now includes a command line tool `wheel sign wheelfile.whl` that adds a digital signature to a wheel file. http://wheel.readthedocs.org/en/latest/index.html#signed-wheel-files