0

I have been tasked with designing a solution for signing source code. I have not found much on whether or not there is a standard for storing the signed code and it's hash and code signing cert.

As I understand it, signing source code involves taking our private key (stored in our HSMs) and encrypting the hash of a source file. Then a signature would be applied to that hash file using the code signing cert.

For one project, there could be 1000's of files needing signed. Where should all of those signed hash files be stored? Is there a standard for the naming of the hash files?

Hope this makes sense. Thanks for any help!

15
  • What problem are you attempting to tackle? Would signed git commits do the trick? If it's for archival, would stuffing it in a tarball and signing the tarball work? What about computing a checksum of every file and signing a file containing checksums? In short - the solution depends on the problem.
    – vidarlo
    Mar 1, 2023 at 17:44
  • It seems like the method that Ubuntu and other linux distros use would work for you. Simply list all the file names and their hashes in a text file. Then, use your private key to sign (not encrypt!) the text file. See releases.ubuntu.com/22.10 as an example - sha256sums is the text file containing the filenames and their hashes, and sha256sums.gpg is the gpg signature of this file, made using Ubuntu's private signing key. discourse.ubuntu.com/t/how-to-verify-your-ubuntu-download/14010 explains how verification is done.
    – mti2935
    Mar 1, 2023 at 18:48
  • 2
    "encrypting a hash" is not what "signing" is. It's a quick and dirty way to explain the process, but that's not what actually happens.
    – schroeder
    Mar 1, 2023 at 19:07
  • @schroeder I am new to the concept of source code signing. From what I have found in trying to research it, it seems that the hash for the source needs to be encrypted. Here is a link I found showing this: pkic.org/uploads/2013/10/CASC-Code-Signing.pdf It seems to follow what most others are stating. Mar 1, 2023 at 20:21
  • 1
    @AustereGrim the signature protects something. Probably the integrity of something, but it's useful to know the threat model and what something happens to be. As I've specified a number of times the solution may depend on what the problem looks like. Everything from signed commits in git to a simple signed tarball may make sense.
    – vidarlo
    Mar 1, 2023 at 22:22

1 Answer 1

1

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;

  1. 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.
  2. 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.
  3. 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.
  4. 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.

3
  • You should probably replace md5 with sha256.
    – vidarlo
    Mar 1, 2023 at 22:24
  • @vidarlo in the hashing? like sha256sum * > hash.sha256 in #2? Mar 1, 2023 at 22:38
  • It's a lot better than md5sum, yes :)
    – vidarlo
    Mar 2, 2023 at 7:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .