feat(image): prevent scanning oversized container images

[nikpivkin]

Description

This PR adds the --max-image-size flag. If the flag is specified and the uncompressed image size exceeds the maximum size, Trivy exits with an error. If the flag is not specified, the behaviour does not change.

For more implementation details, see #8176

Related issues

• Close feat: prevent scanning oversized container images #8176

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
• I've added usage information (if the PR introduces new options)
• I've included a "before" and "after" example to the description (if the PR is a user interface change).

[nikpivkin]

@knqyf263 I was thinking that we could download the compressed layer and then decompress it ourselves. I saw that downloader.Download is used for decompression. Does it support all the compression types that go-containerregistry does?

[knqyf263]

This is what was in my mind.

	layer, err := a.image.LayerByDiffID(h)
	if err != nil {...}

	rc, err := layer.Uncompressed()
	if err != nil {...}

	f, err := os.Open(diffID + ".tar")
	if err != nil{...}

	io.Copy(f, rc)

[nikpivkin]

@knqyf263 Then we can't display the progress bar correctly, because we don't know the size of the uncompressed layer.

[knqyf263]

Can't we use the progress in ggcr?
https://github.com/google/go-containerregistry/blob/6bce25ecf0297c1aa9072bc665b5cf58d53e1c54/pkg/v1/remote/progress.go#L25

[knqyf263]

If it doesn't work, we can use layer.Compressed, inject the progress bar and re-implement uncompressed logic.
https://github.com/google/go-containerregistry/blob/6bce25ecf0297c1aa9072bc665b5cf58d53e1c54/pkg/v1/partial/compressed.go#L50-L78

[nikpivkin]

@knqyf263 I kept the old behavior, if no flag is passed, to avoid unnecessary disk operations. But then the progress bar will be displayed only when the flag is passed. What do you think?

[knqyf263]

Each artifact must have Clean() method so that the caller can be responsible for cleanup. What if moving that to Clean()? It might help in case Inspect() is called several times (we don't assume such usage, though).

[nikpivkin]

Done bba405b

[knqyf263]

nit: Trivy already has several kinds of cache, like scan cache, cache assets, etc. cacheDir looks like the root directory of the cache directory controlled by --cache-dir. I'd rename it to the explicit name.

Suggested change

	cacheDir string
	layerCacheDir string

[nikpivkin]

Done bba405b

[knqyf263]

@nikpivkin I got an idea.
https://go.dev/play/p/fY8jM99don_r

[knqyf263]

This might be better.

// ProgressLayer wraps a v1.Layer to add progress bar functionality
type ProgressLayer struct {
	v1.Layer
}

func NewProgressLayer(layer v1.Layer) *ProgressLayer {
	return &ProgressLayer{ Layer: layer, }
}

func (l *ProgressLayer) Compressed() (io.ReadCloser, error) {
	size, err := l.Layer.Size()
	if err != nil {
		return nil, err
	}

	rc, err := l.Layer.Compressed()
	if err != nil {
		return nil, err
	}

	bar := pb.Full.Start64(size)
	bar.Set(pb.Bytes, true)

	return bar.NewProxyReader(rc), nil
}

[knqyf263]

Even better

// progressLayer wraps a v1.Layer to add progress bar functionality
type progressLayer struct {
	v1.Layer
}

func (l *progressLayer) Compressed() (io.ReadCloser, error) {
	rc, err := l.Layer.Compressed()
	if err != nil {
		return nil, err
	}

	size, err := l.Layer.Size()
	if err != nil {
		return nil, err
	}

	bar := pb.Full.Start64(size)
	bar.Set(pb.Bytes, true)

	return bar.NewProxyReader(rc), nil
}

func NewProgressLayer(layer v1.Layer) (v1.Layer, error) {
	return partial.CompressedToLayer(&progressLayer{ Layer: layer})
}

[nikpivkin]

@knqyf263 Ok, I'll think about how to use this with the progress bar pool otherwise there is flickering in the terminal when loading in parallel

[knqyf263]

@nikpivkin Actually, the progress bar should be discussed in #8186. I'll re-post it there.

[DmitriyLewen]

We can wait for feedback from users.
But perhaps some users will want to set custom exit code.