ddeschenes-1 opened a new pull request, #618: URL: https://github.com/apache/commons-compress/pull/618
When gzip parameters' filename or comment are encoded into bytes, no verification was made to avoid the \0 that internally terminates those gzip fields. Thus, the string argument could have a \0, and/or encode into bytes that have a \0 (like with UTF-16 charsets). This would silently corrupt the gzip member, as a reader would prematurely stop reading the filename or comment and begin reading the next piece, either the comment but inevitably the deflate stream, which would fail. I thought also about limiting the length on write but the gzip spec has no limit. Limiting length on read (to protect memory) would be imposing an arbitrary limit too, like some gzip tools do. Either way, it would have to be an option like the charset on write, and it would be unusual to ask for such option on the GzipDecompressorInputStream. Using jdk 17 ScopedValues is not possible yet and it would be a very forgettable option to set anyway. Without some discussion, there is no point in placing another api facing change on constructors. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
