UPSTREAM PR #29131: Make our sbom generation useful#78
Open
Conversation
DajanaV
force-pushed
the
upstream-PR29131-branch_nhorman-sbom
branch
from
532c3be to
6b6807e
Compare
DajanaV
force-pushed
the
main
branch
5 times, most recently
from
9eedffa to
3c38188
Compare
DajanaV
force-pushed
the
upstream-PR29131-branch_nhorman-sbom
branch
2 times, most recently
from
83132e2 to
46103ab
Compare
DajanaV
force-pushed
the
main
branch
2 times, most recently
from
ea7034c to
7c8c5e7
Compare
loci-dev
force-pushed
the
main
branch
2 times, most recently
from
408910b to
5585f8f
Compare
We currently have an SBOM file, but its not at all useful, in that its just a template that downstream consumers might use to build their own sboms, but thats not really what an SBOM is for. SBOMs provide a level of assurance that the release production process was done securely. OpenSSL produces source releases, for which we leverage git archive when done on a github CI runner, which we don't have direct control over (at least not the contents of the runner image), so what we really should be doing, is generating an SBOM on the fly, for which we validate the computed SHA256 sum of each file in the tarball against the SHA256 sum of the corresponding file from the source git tree (to ensure that tooling local to the system didn't modify the files during archive construction. Replace the static sbom file with some additional ci work to do that, and make the sbom part of the release process so that downstream users can properly consume it.
loci-dev
force-pushed
the
upstream-PR29131-branch_nhorman-sbom
branch
from
46103ab to
27bfa5d
Compare
loci-dev
force-pushed
the
main
branch
11 times, most recently
from
bfc0664 to
016ec45
Compare
loci-dev
force-pushed
the
main
branch
4 times, most recently
from
95e9e21 to
4bc0459
Compare
loci-dev
force-pushed
the
main
branch
12 times, most recently
from
7e34ff8 to
ef954d1
Compare
loci-dev
force-pushed
the
main
branch
10 times, most recently
from
4ccbb9d to
1a7d0ff
Compare
loci-dev
force-pushed
the
main
branch
7 times, most recently
from
d1b2335 to
3b3711a
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Mirrored from openssl/openssl#29131
We currently have an SBOM file, but its not at all useful, in that its just a template that downstream consumers might use to build their own sboms, but thats not really what an SBOM is for.
SBOMs provide a level of assurance that the release production process was done securely. OpenSSL produces source releases, for which we leverage git archive when done on a github CI runner, which we don't have direct control over (at least not the contents of the runner image), so what we really should be doing, is generating an SBOM on the fly, for which we validate the computed SHA256 sum of each file in the tarball against the SHA256 sum of the corresponding file from the source git tree (to ensure that tooling local to the system didn't modify the files during archive construction.
Replace the static sbom file with some additional ci work to do that, and make the sbom part of the release process so that downstream users can properly consume it.