feat: add cryptographic asset model and parser#10970
Conversation
knqyf263
added
the
kind/feature
f9f77cf to
0e856fc
Compare
0e856fc to
fea60fe
Compare
| } | ||
|
|
||
| // Asset describes a format-neutral cryptographic asset. | ||
| type Asset struct { |
There was a problem hiding this comment.
Have you considered moving Asset and everything related to it into fanal/types?
All the fields in AnalysisResult are fields from ftypes:
trivy/pkg/fanal/analyzer/analyzer.go
Lines 180 to 186 in b7ce181
On top of that, we use
Asset as an analysis result, which also fits this change.The fields of
Asset and the other structs are exported, so there shouldn't be any problems with this move.I understand that the amount of code involved in this package is many times larger than for any type in
fanal/types, but in that case we could think about creating a subpackage.In addition, this would get rid of the circular import problem with
layers.
But I might have missed something.
| {name: "lowercase PEM", filePath: "certificates/server.pem", want: true}, | ||
| {name: "uppercase PEM", filePath: "certificates/server.PEM", want: true}, | ||
| {name: "mixed-case PEM", filePath: "certificates/server.PeM", want: true}, | ||
| {name: "lowercase DER", filePath: "certificates/server.der", want: true}, | ||
| {name: "uppercase DER", filePath: "certificates/server.DER", want: true}, | ||
| {name: "mixed-case DER", filePath: "certificates/server.DeR", want: true}, | ||
| {name: "lowercase CRT", filePath: "certificates/server.crt", want: true}, | ||
| {name: "uppercase CRT", filePath: "certificates/server.CRT", want: true}, | ||
| {name: "mixed-case CRT", filePath: "certificates/server.CrT", want: true}, | ||
| {name: "lowercase CER", filePath: "certificates/server.cer", want: true}, | ||
| {name: "uppercase CER", filePath: "certificates/server.CER", want: true}, | ||
| {name: "mixed-case CER", filePath: "certificates/server.CeR", want: true}, | ||
| {name: "lowercase KEY", filePath: "certificates/server.key", want: true}, | ||
| {name: "uppercase KEY", filePath: "certificates/server.KEY", want: true}, | ||
| {name: "mixed-case KEY", filePath: "certificates/server.KeY", want: true}, |
There was a problem hiding this comment.
We already have the tests for the Contains() function from set.NewCaseInsensitive.
So I think checking each ext once will be enough.
| }) | ||
|
|
||
| // Cryptographic assets | ||
| sort.SliceStable(r.CryptoAssets, func(i, j int) bool { |
There was a problem hiding this comment.
Could you explain in more detail why sort.SliceStable is needed here?
If we have assets with the same FilePath and Descriptor and we don't remove them as duplicates, then it might make sense to add more values for comparison.
I don't think we'll have enough entries to worry about the speed difference between sort.Slice and sort.SliceStable, but from a code consistency perspective, we could go with sort.Slice.
2 participants
Description
Add the format-neutral cryptographic asset foundation for container image CBOM support.
This PR:
pkg/cryptoThe parser returns only public metadata for plaintext private keys and does not retain private-key material in its results. Encrypted PKCS#8 containers are treated as opaque assets and identified by their SHA-256 digest.
This PR does not add user-facing scanner behavior. Analyzer and extractor integration, scanner registration, and CycloneDX output will be implemented in follow-up PRs.
Related issues
Related discussion
Checklist