zlib: fix gzip member head/buffer boundary issue (backport of #5883) #5973
Conversation
|
@addaleax Is it possible you have the wrong base here? |
|
@Fishrock123 nope, that is on me. I had to remove a commit from v5.x because it ended up depending on a semver-major change. |
addaleax
force-pushed
the
backport-5883-to-5.x
branch
2 times, most recently
from
d1059e3
to
0810475
Compare
|
Okay, @evanlucas beat me to answering – rebased this either way. :) |
|
@addaleax Can you do another rebase and force-push? The diff is currently +6,516 −650 with 728 files changed. The zlib changes LGTM at a glance except for a style issue (capitalization/punctuation of comments.) |
Make sure that, even if an `inflate()` call only sees the first few bytes of a following gzip member, all members are decompressed and part of the full output. Adds tests for the special case that the first `inflate()` call receives only the first few bytes of a second gzip member but not the whole header (or even just the magic bytes). This is a backport of nodejs#5883 and contains additional changes to make sure that the behaviour on encountering trailing garbage remains the same (namely to silently discard it if one full member has already been decompressed). #PR-URL: nodejs#5883 #Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> #Reviewed-By: James M Snell <jasnell@gmail.com>
addaleax
force-pushed
the
backport-5883-to-5.x
branch
from
0810475
to
172c991
Compare
|
Sure, that seems to have been another force-push to v5.x. Anyway, rebased + updated the comment in node_zlib.cc (Left the ones in the test files as they are in master). |
|
New CI: https://ci.nodejs.org/job/node-test-pull-request/2206/ |
|
LGTM if CI is green. |
|
New CI: https://ci.nodejs.org/job/node-test-pull-request/2265/ - looks like transient issues with the previous one. |
|
Yup, CI is green now 👍 |
Make sure that, even if an `inflate()` call only sees the first few bytes of a following gzip member, all members are decompressed and part of the full output. Adds tests for the special case that the first `inflate()` call receives only the first few bytes of a second gzip member but not the whole header (or even just the magic bytes). This is a backport of #5883 and contains additional changes to make sure that the behaviour on encountering trailing garbage remains the same (namely to silently discard it if one full member has already been decompressed). PR-URL: #5973 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com>
|
Landed in 61167c3 |
Pull Request check-list
Please make sure to review and check all of these items:
make -j8 test(UNIX) orvcbuild test nosign(Windows) pass withthis change (including linting)?
test (or a benchmark) included?
Affected core subsystem(s)
zlib
Description of change
This is squashed together from the corresponding commit in master and this commit to make sure behaviour stays the same as in previous 5.x releases.
Make sure that, even if an
inflate()call only sees the first few bytes of a following gzip member, all members are decompressed and part of the full output.Adds tests for the special case that the first
inflate()call receives only the first few bytes of a second gzip member but not the whole header (or even just the magic bytes).This is a backport of #5883 and contains additional changes to make sure that the behaviour on encountering trailing garbage remains the same (namely to silently discard it if one full member has already been decompressed).