Checksum of file downloaded from git

This page describes how to verify a file, downloaded from a mirror, by checksum or by signature.

All official releases of code distributed by the Apache Software Foundation are signed by the release manager for the release. PGP signatures and SHA/MD5 checksums are available along with the distribution.

You are encouraged to download the releases from our mirrors. Signatures and checksums are only available from the official Apache Software Foundation site.
Our download pages point you to the mirrors for releases and to the official site for signatures and checksums.

Checking Hashes¶

File hashes are used to check that a file has been downloaded correctly. They do not provide any guarantees as to the authenticity of the file.

The checksum of a file is a fixed length string, that (in practice) uniquely identifies the contents of the file. Two files are (only) equal if their checksums are equal. Comparing the checksums of two files is as good as comparing the two files themselves.

There are lots of checksum algorithms ; we use SHA-1, SHA-256, SHA-512 and MD5.
The download page shows which checksum files are available for the original file.

To check a hash, you have to compute the proper checksum of the file you just downloaded ; then compare it with the published checksum of the original.

Only if you check the hash can you be certain that your download hasn't been modified ; for instance on the mirror - or the download itself may be incomplete or faulty.

Checking Signatures¶

The following example details how signature interaction works. The example is for the Apache HTTP Server project, but applies equally to other ASF projects.

In this example, you are already assumed to have downloaded (the release) and (the detached signature).

This example uses The GNU Privacy Guard. Any OpenPGP-compliant program should work successfully.

First, we will check the detached signature () against our release ().

N.B. you must specify both the detached signature and the release file.
If the release file is omitted, GPG will only check the signature against the release file if the signature is a detached signature. If the .asc file is a self-contained signed file, GPG will only check that, and will not verify the release. (This should not happen if the signature file was downloaded from an ASF server, but it is safer to always specify the release filename)

This means that we don't have the release manager's public key () in our local system. You now need to retrieve the public key from a key server. One popular server is (which has a web interface ). The public key servers are linked together, so you should be able to connect to any key server.

In this example, you have now received a public key for an entity known as 'Sander Striker <striker@apache.org>' However, you have no way of verifying this key was created by the person known as Sander Striker. But, let's try to verify the release signature again.

At this point, the signature is good, but we don't trust this key. A good signature means that the file has not been tampered with. However, due to the nature of public key cryptography, you need to additionally verify that key was created by the real Sander Striker.

Any attacker can create a public key and upload it to the public key servers. They can then create a malicious release signed by this fake key. Then, if you tried to verify the signature of this corrupt release, it would succeed because the key was not the 'real' key. Therefore, you need to validate the authenticity of this key.

Validating Authenticity of a Key¶

You may download public keys for the Apache project developers from our website or retrieve them from the public PGP keyservers (see above). However, importing these keys is not enough to verify the integrity of the signatures. If a release verifies as good, you need to validate that the key was created by an official representative of the Apache HTTP Server Project.

The crucial step to validation is to confirm the key fingerprint of the public key.

A good start to validating a key is by face-to-face communication with multiple government-issued photo identification confirmations. However, each person is free to have their own standards for determining the authenticity of a key. Some people are satisfied by reading the key signature over a telephone (voice verification). For more information on determining what level of trust works best for you, please read the GNU Privacy Handbook section on Validating other keys on your public keyring.

Most of the Apache HTTP Server developers have attempted to sign each others' keys (usually with face-to-face validation). Therefore, in order to enter the web of trust, you should only need to validate one person in our web of trust. (Hint: all of our developers' keys are in the KEYS file.)

For example, the following people have signed the public key for Sander Striker. If you verify any key on this list, you will have a trust path to the key. If you verify a key that verifies one of the signatories for , then you will have a trust path. (So on, and so on.)

Since the developers are usually quite busy, you may not immediately find success in someone who is willing to meet face-to-face (they may not even respond to your emails because they are so busy!). If you do not have a developer nearby or have trouble locating a suitable person, please send an email to the address of the key you are attempting to verify. They may be able to find someone who will be willing to validate their key or arrange alternate mechanisms for validation.

Once you have entered the web of trust, you should see the following upon verifying the signature of a release.