Clever Geek Handbook

What is the purpose of the signature file (* .SF) when signing a jar file?

As I found out from https://docs.oracle.com/javase/tutorial/deployment/jar/intro.html , the procedure for signing a jar file with jarsigner is as follows:

  • The manifest file is updated with a list of hashes for each file:

    Name: com / qarks / util / files / diff / ui / main / DiffMergeFrame.class SHA-256 digest: GZgPXG9YnmVGXb + hFwnJF4im4hb / qixX2Gs + ZNpdGFU =

    Name: com / qarks / util / ui / swing / PrintManager.class SHA-256 digest: cO6XolXrk5NlHBocDF0fzojlwSAKlDoGsY / jdJ0fzdY =

  • A signature file (* .SF) is generated. It contains:

    • hash of the manifest file
    • a hash of the main attributes in the manifest file
    • hashes hashes for each file from the manifest file.

  • Signature block file (* .RSA, * .DSA) has been created. It preserves the digital signature of the * .SF signature file.

So, I would like to know why we need * .SF at all - why can't we just sign the manifest file instead of the * .SF file?

And also the purpose of hashes of hashes in * .SF file (additional check? In what cases?)?

+3


source to share


1 answer


Signature file ( .SF

) represents the file signer .jar

- technically there can be more than one.

To answer your second question, imagine a case where a file .jar

changes after it has already been signed. The file manifest

would have changed and so the hash in .SF

( *-Digest-Manifest

) would no longer match the current file .manifest

.

However, if .jar

only new files were added to it, it still passed the validation, since the validation algorithm (among other things) looks at each entry in .SF

and checks the hashes against the corresponding entries in manifest

(new entries in manifest

will be ignored).



To summarize, this is .SF

used to verify that none of the files present at .jar

the time of signing has been modified.

Read more about signature verification here .

+2


source






More articles:


All Articles