uzlib: update to more robust version of uzlib#818
Conversation
Textualy, the files in lib/uzlib/src were identical to the ones committed in extmod/uzlib so there should be no behavioral change possible as a result of this commit.
|
Where did pfalcon get the code? Is it possible we should rely on a further upstream? We can also change the submodule source later too. |
|
From what I've been able to discern, uzlib is based on tinf/tinflate at https://bitbucket.org/jibsen/tinf -- tinf appears to be unmaintained, is only an inflate (not deflate) implementation, and is designed to only accept trusted inputs -- "the zlib library has many more features, is more secure, and mostly faster ... it does assume it is given valid compressed data". I don't think we can switch to tinf as upstream. pfalcon has been receptive to my PR (but with changes requested), so let's give that some time to shake out before we really decide we have to switch upstreams. |
|
Sounds good! Thanks for the follow up.
…On Tue, May 8, 2018 at 1:51 PM Jeff Epler ***@***.***> wrote:
From what I've been able to discern, uzlib is based on tinf/tinflate at
https://bitbucket.org/jibsen/tinf -- tinf appears to be unmaintained, is
only an inflate (not deflate) implementation, and is designed to only
accept trusted inputs -- "the zlib library has many more features, is more
secure, and mostly faster ... it does assume it is given valid compressed
data". I don't think we can switch to tinf as upstream.
pfalcon has been receptive to my PR (but with changes requested), so let's
give that some time to shake out before we really decide we have to switch
upstreams.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#818 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADNqVhvPuopO5OmnenKTV0lJLxpdptnks5twgVOgaJpZM4T14Nm>
.
|
|
@jepler Please create a new PR when changes are upstream. Thanks! |
2 participants
This one should probably be considered more a "request for comments" than a "ready to be merged".
I will be throwing a fuzzer at circuitpython with this patch, to see if anything new pops up; probably something will, because circuitpython can also use the stream-mode decompressor which was not fuzzed as yet.
We also need to consider the best way to refer to the submodule; I don't particularly desire putting myself forward as a long-term maintainer of uzlib, which would sort of be implied if this patch were accepted pointing at my personal fork of uzlib.