search

RedHatProductSecurity / security-data-guidelines

A set of documents detailing Red Hat's publishing of security data.
https://redhatproductsecurity.github.io/security-data-guidelines/
MIT License
1 stars 1 forks source link

RPM checksums #27

Closed tkopecek closed 1 month ago

tkopecek commented 1 month ago

We can either store checksum of whole file as it is done for most other components or store sigmd5. The question is if signatures are relevant here or if SBOM really care about the content. Attack on sigmd5 is of course theoretically possible. OTOH, it is a question if differently signed RPMs are really different from SBOMs point of view. I lean to store whole checksum anyway, but then there is a second set of questions related to signatures themselves. Does it make sense to store information about them? I was thinking about putting signatures and sigmd5 into annotations (OTHER type). Any hints?

mprpic commented 1 month ago

The checksum of the package itself is a must, but I don't think there is any downside to providing both. Using annotations sounds good to me, e.g.:

  "checksums": [
    {
      "algorithm": "SHA256",
      "checksumValue": "abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234abcd1234"
    }
  ],
  "annotations": [
    {
      "annotationType": "OTHER",
      "annotator": "Tool: <Build System>",
      "annotationDate": "<can be same as creationInfo.created>",
      "comment": "sigmd5: <value>"
    }
  ]

Note that the value may change between a build-time SBOM and a release-time SBOM, depending on whether the signing happens when the RPM is being released.