Provenance build-step analysis
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
- Issue type
- Feature
- Clarity
- Needs clarification
- Activity status
- Stale
- Tech stack
- go
- Domain
- build-system, devtools
Research direction
No source files or tests are named. Start by locating the image inspection entry points and determining how provenance attestations, sourcemaps, LLB, and image config history are represented; done would require an agreed design for build-step lookup and source mapping, including the proposed Image, BuildStepIdentifier, and BuildStep concepts.
Written by the indexing model from the issue text.
Description
We can use the new SLSA provenance attestations to extract source information from an image.
Example use cases:
- Provide a more accurate image history view (e.g. on hub)
We should provide a way to lookup build step identifiers (e.g. sha256 digests, diffids, stage numbers, etc) in the sourcemap and return the LLB used to build it, as well as the source-mapping for the original component - I think it should be valid to allow a flexible lookup using different types of identifiers for this?
If SLSA provenance isn't available, we should provide fallbacks using the image config history - we can't reconstruct the LLB, but we can some guesses as to the original source code and build-steps using the layers - though this is definitely outside the initial scope.
For example, a struct might look something like this:
type Image struct {
// ...
BuildSteps []BuildStep
}
// GetBuildStep is a helper utility to get a BuildStep using a BuildStepIdentifier, could be an interface or similar that could be the sha256 digest of the layer, the DiffID for that layer, the stage name for that layer, etc.
func (img Image) GetBuildStep(id BuildStepIdentifier) BuildStep { ... }
type BuildStep struct {
Digest digest.Digest
DiffID digest.Digest
Stage string // e.g. stage0
LLB
Source
}
Ideally, if we can, we should represent Source in a VCS-rich way, so not only should it be possible to get the string that represents that snippet, but if we have Git metadata, we can attempt to link it back to source.
- Dominant language
- Go
- Stars
- 15
- Forks
- 4
- PR merge metrics
- No merged PRs in 30d
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- Read the contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from docker/go-imageinspect
-
Difficulty 3/5 1-2 days Newbie friendliness 45/100
docker/go-imageinspect#22 ·
-
Difficulty 5/5 Over a week Newbie friendliness 35/100
docker/go-imageinspect#21 ·
-
Difficulty 5/5 Over a week Newbie friendliness 30/100
docker/go-imageinspect#14 · 1 comment ·
-
Difficulty 5/5 Over a week Newbie friendliness 32/100
docker/go-imageinspect#13 · 1 comment ·
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
docker/go-imageinspect#11 ·
All issues in docker/go-imageinspect
Similar issues
-
documentation ready
Difficulty 1/5 Under an hour Newbie friendliness 88/100
Maintainers usually reply within 1 day
-
Needs Triage
Difficulty 1/5 Under an hour Newbie friendliness 90/100
-
bug good first issue
Difficulty 2/5 1-3 hours Newbie friendliness 74/100
solongate/agent-security#154 ·
Maintainers usually reply within 1 day
-
tree: RootStyle is applied twice to the root nodePossibly taken @PhotoDotPi claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
charmbracelet/lipgloss#772 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 76/100
Maintainers usually reply within 1 day