I did some background checking: the sign file is actually the "sign-off" 
signature of the corresponding git version tag. The meaning of this 
"sign-off" value is defined by the project. In many open source projects it 
means that the contribution is original and that there are no copyright 

Note that comparing the hashes as you did has a different purpose than 
verifying a signature. If you want to check that a file is not corrupted, 
hashes are the way to go. Otherwise, clone the git repository.

On Thursday, June 22, 2017 at 6:15:26 PM UTC+2, David Karr wrote:
> On Thursday, June 22, 2017 at 8:49:30 AM UTC-7, Tamar wrote:
>> The .sign files are PGP files. I suspect you can verify the signature 
>> like this (didn't check):
>> *gpg --verify doc.sig doc*
> I managed to resolve this.  This "gpg" command doesn't work, because I 
> don't have the public key, but I did notice the "sha256sums.asc" file in 
> the same directory, and I used "sha256sum" to generate the sum to compare 
> with.
>> See https://www.gnupg.org/gph/en/manual/x135.html for a complete story 
>> on how to use signatures and how to verify them.
>> On Thursday, June 22, 2017 at 5:43:32 PM UTC+2, David Karr wrote:
>>> At https://www.kernel.org/pub/software/scm/git/ , there are tar files 
>>> (both .xz and .gz compressed), and "sign" files.  I assume the "sign" file 
>>> is a signature used to verify the tar file.  The documentation does mention 
>>> that there are signature files that can be used to verify the installation, 
>>> but it doesn't say how to do that.

You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to