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

Decoding limits #28

Merged
merged 3 commits into from
Jun 9, 2018
Merged

Decoding limits #28

merged 3 commits into from
Jun 9, 2018

Conversation

newpavlov
Copy link
Contributor

@newpavlov newpavlov commented Jun 8, 2018

Limits can be configured by providing Limits value to new methods. Default values allow maximum size of DecodingImage's data equal to 2^26, which is equal to 512 MB.

It's better to merge this PR first, after it I'll add limits to fuzzing in #26 .

Ok(Decoder { info, rac })
}

pub fn new_with_limits(reader: R, limits: Limits) -> Result<Self> {
Copy link
Owner

Choose a reason for hiding this comment

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

Change to with_limits, this matches the convention on structs like Vec


// read the metadata chunks
let (metadata, non_optional_byte) = Metadata::all_from_reader(&mut reader)?;
let (metadata, non_opt_byte) = Metadata::all_from_reader(&mut reader, &limits)?;
Copy link
Owner

Choose a reason for hiding this comment

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

no need to shorten non_optional_byte here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Line becomes too long in my opinion and breaking line on :: or arguments does not look good here. But ok, will revert it.

@@ -72,6 +76,27 @@ impl Flif {
}
}

/// Limits on input images to prevent OOM based DoS
#[derive(Copy, Clone ,Debug)]
pub struct Limits {
Copy link
Owner

Choose a reason for hiding this comment

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

It may be useful to add a limit for the maniac tree in this PR. If we add it later it will be a breaking change since it will add a new field to the struct.

The limit doesn't have to do anything yet, but to prevent API breakage it should at least exist on the Limits type

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will it be enough to have one maniac_depth: usize field?

Copy link
Owner

Choose a reason for hiding this comment

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

It might be better to have a maniac_nodes: usize field, since there could be very lopsided maniac trees that wouldn't take up as much space as a balanced tree of smaller depth.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done. For now default limit is 1024.

Copy link
Owner

Choose a reason for hiding this comment

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

It might be a good idea to set that to 4096. That seems like a lot but if remember correctly the sea snail image has 1100ish nodes. There may be more in larger images.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done.

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.

2 participants