Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Verify size in verify.ReadCloser #1044

Merged
merged 3 commits into from
Jun 11, 2021
Merged

Verify size in verify.ReadCloser #1044

merged 3 commits into from
Jun 11, 2021

Conversation

imjasonh
Copy link
Collaborator

This prevents cases where a descriptor says it describes a 100-byte blob, but then serves 1TB blob, which could lead to resource exhaustion. Instead, we'll only read as many bytes as the descriptor claims there should be, and fail if the digest doesn't match after reading that many. This also verifies the content isn't shorter than described.

This adds a HEAD request to remote.Layer to fetch the size of the blob before reading and verifying it. If that's not acceptable we could work around it.

@jonjohnsonjr
Copy link
Collaborator

I'm tempted to have these be separate things because in some cases we don't know the size but we do know the digest (e.g. diffids and schema 1).

@imjasonh
Copy link
Collaborator Author

I'm tempted to have these be separate things because in some cases we don't know the size but we do know the digest (e.g. diffids and schema 1).

That's reasonable. It doesn't look like we use verify at all with either of those though, so maybe we should update verify.ReadCloser to take size into account, then add verify.ReadCloserNoSize (naming tbd) when we need it. That might be something we could use with remote.Layer for instance.

@jonjohnsonjr
Copy link
Collaborator

That might be something we could use with remote.Layer for instance.

Might still be useful to use the Content-Length for that, but also the response body probably does that itself... we should maybe be confirming Size == Content-Length and doing a LimitReader?

@codecov-commenter
Copy link

codecov-commenter commented Jun 11, 2021

Codecov Report

Merging #1044 (c404bd4) into main (f0ce227) will increase coverage by 0.09%.
The diff coverage is 86.66%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main    #1044      +/-   ##
==========================================
+ Coverage   75.03%   75.13%   +0.09%     
==========================================
  Files         107      107              
  Lines        5079     5083       +4     
==========================================
+ Hits         3811     3819       +8     
+ Misses        725      719       -6     
- Partials      543      545       +2     
Impacted Files Coverage Δ
pkg/v1/remote/descriptor.go 73.36% <71.42%> (ø)
internal/verify/verify.go 100.00% <100.00%> (ø)
pkg/v1/remote/image.go 79.72% <100.00%> (ø)
pkg/v1/tarball/image.go 76.82% <0.00%> (+2.43%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f0ce227...c404bd4. Read the comment docs.

@imjasonh
Copy link
Collaborator Author

I decided to verify using Content-Length in fetchBlob so that remote.Layer doesn't have to do a HEAD. This made the diff smaller.

Copy link
Collaborator

@jonjohnsonjr jonjohnsonjr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to validate config blob size as well?

body, err := r.fetchBlob(r.context, m.Config.Digest)

pkg/v1/remote/descriptor.go Outdated Show resolved Hide resolved
@imjasonh
Copy link
Collaborator Author

Do we want to validate config blob size as well?

body, err := r.fetchBlob(r.context, m.Config.Digest)

That'll be validated against the Content-Length at least. I'm not sure what to do if the descriptor size disagrees with the content-length header. Nothing would catch that with this version, but nothing would have caught it before either AFAIK.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants