Okay, after reading the discussion I think I have a way to answer your questions. However you brought up the paper of "CASC Code Signing", this is "executable code signing" (publisher verification) and not related to "source code signing" (tracking/validating changes to source file) which is what I'm outlining below, they do use similar concepts of signing the files.
I have been tasked with designing a solution for signing source code.
You probably don't want to design a new solution, but try to find an existing solution instead. Signed commits in a git server might be all you're looking to really do, especially if the code is still in active development.
The discussion didn't clarify the end purpose of the signing of source code, so my response is from a change management perspective, that being your organziation is trying to comply with a policy where changes need to be tracked and approved. Validating those changes are approved and not modified without approval is to be performed via file signature.
sign all of our source code to not only authenticate but also show what security classification the source is certified at
You should rely on the source code submitters to "certify" the classification. Something as simple as portion markings and file markings should be appropriate, but follow your organization's policy on that.
Where should all of those signed hash files be stored?
Following the discussion you have some options;
- You can sign each file individually and store the signature file with each file.
- This validates each file has not been changed, and can store a copy of the signed file in the signature file itself. (This can be unwieldy and space consuming.)
- Validation process itself could be time consuming.
- You can hash out all the files (
sha256sum * > hash.sha256) storing just the hashes in a text file, and sign only that hash list file (gpg --output hash.sha256.gpg --sign hash.sha256), store that signed file with the file.
- This is how software repositories allow you to validate you're getting unmodified versions of software, ie. Ubuntu.
- This validates the hash list file has not be changed, which itself validates that the sources have not been changed.
- Validation of this is fast as you just need to create a new hash list, and compare the differences between the old and new hash lists.
- You can have some sort of database maintain it. (Git for example can use a MySQL database.)
- This keeps everything in a managed system with tracked changes.
- Validation is automatic.
- Create an archive of the entire source and hash and/or sign the tar file.
- For archiving, and not for tracking changes. This is more for along the lines of verifying that file corruption has not happened.
Depending on your organizaiton's requirements I think option 2 or 3 is probably what you're looking to do.
Some research from the link below; contrary to my point in the discussion, by default with gpg you don't just create a signature of the file, or just a hash result. It is a copy of the source file compressed, and ammended a signaure block into the output file. You can create just a detached signature (gpg --output doc.sig --detach-sig doc) where you would need the source file and that signature file to perform validation.
In the instance where you do create a copy, it's not technically "encryption" merely compression, but perceptively compression is a method of weak encryption. And gpg does use the option named "--decrypt" to extract the source.
Is there a standard for the naming of the hash files?
Hash lists of files typically are named extensions with the hash method used. .md5, .sha256... or I've seen .md5.txt sometimes.
The signed file would be the signing method, ie. .gpg, so the signature file of sourcefile1.txt could be sourcefile1.txt.gpg (this follows Ubuntu's signing format.)
gnupg.org uses .sig in an example, but there's no real requirement for it.
