-
Notifications
You must be signed in to change notification settings - Fork 629
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
Release version 0.22 #973
Release version 0.22 #973
Conversation
Replaces image-rs#885, or rather was discovered during it as it was originally trying to reason abouts its safety.
This just makes life easier.
The command used to rename is also added to the minimization script, to avoid producing the same issue in future corpus directories and to have a reference if necessary.
Most uncomplete matches are removed by creating proper enums in the webp implementation and parsing to those constant variants early on. Some unsupported operations are explicitely failed with a Unsupported error variant.
Includes two seeds that were small enough to be viable. They are simply converted (with imagemagick) samples from the tests/images/ directory. This is good enough for the first few failures and panics. If you want a larger corpus, you can put other images into the directory although larger images can slow the fuzzer down without necessarily giving larger coverage.
This seems to originate from one of the samples provided in the RFC, specifically on page 23. A working version, that does the check for its input length, can be found in the attached implementation in section 20. This error is diagnosed as a FormatError.
A partition not containing as much data as claimed in the header is a format error. While ignoring it at that moment will likely lead to some later issues, it is better to check that the read has indeed taken place.
Simply do not refresh the cache state when bits are required during the decoding process than can be read into the decoder. This strategy is suggested in the reference implementation of the RFC.
At least one of the table entries can exceed the range of a signed 16-bit integer in an intermediate result. The reference implementation used an `int` of unspecified width for this but this is wasteful in terms of size of the table (albeit only slightly since the table is small).
Some of the operations can overflow in i32, according to debug mode builds. This is not intentional as the math is applied to conceptual fixed point numbers.
Backport of fixes to release 0.21.2
chore: Update glob to 0.3
@fintelia I'm not sure what to do, I see no easy way to make this work. Together with Any ideas? |
I'd be in favor of just bumping the minimum supported version whenever our dependencies do. Without ecosystem wide guidance, deciding when to bump is mostly guesswork anyways. The past comment about what version we'd have to advance to is gone (lost in the force push?) but if I recall correctly it was 1.26.1 which is just ever so slightly more than a year old. Supporting a year of past versions seems like a very reasonable policy |
The dependency of |
Ok, then how to select the version to use and which version? At least the current requirement of all our fully updated dependencies but possibly more. Like |
I really don't have any ideas on how to pick a version, and I'm fine with pretty much anything at least a few releases ago. The first release with |
Which would be |
Will the API change suggested in #901 be part of version 0.22 ? |
@lovasoa There are a few open points of discussion that have yet to be addressed. I'd personally be happy if they can be answered before the release (and included) but don't want to delay for too long. |
Debian Buster is scheduled to release as stable today and includes Rust |
I support using 1.34.2 since its in debian stable starting today |
That sounds good to me, although I don't think we should commit to always supporting the Rust version in Debian stable since that can potentially get to be several years old. |
In particular also references the web page and blog.
As discussed in #865 we're deferring the changes to
ColorType
onto anotherbranch and/or prerelease versions of the next api for now due to several other
API changes that await release. The same seems sensible for the error cleanup.
This is a huge merge commit to ensure we don't miss any changes that
happened in the version-0.21 branch.
This is also a call to suggest outstanding breaking changes that should be part
of 0.22, such as #901.