bdw-g commented on PR #673: URL: https://github.com/apache/commons-compress/pull/673#issuecomment-2926619146
I'm not sure I understand why binary compatiblity would still be broken, can you elaborate? > Because of this inlining behavior, introducing a separate ArchiveStreamConstants class might not provide the benefits you're aiming for, since the constants are effectively duplicated and the new class doesn't reduce dependencies in practice. I don't care about that. What I care about is the ability to build independent 'archiver' libraries, for instance, for ZIP, TAR, and other formats, and similarly for 'compressor' libraries. This is currently impossible because, for instance, the file `ZipSplitReadOnlySeekableByteChannel` references `ArchiveStreamFactory`, and obviously `ArchiveStreamFactory` depends on `ZipArchiveInputStream` etc. So compiling the zip archiver inevitably brings in the whole library. The reason I care about that is that I maintain the source code for apache commons-compress at google, and it has been a common occurrence that there is a vulnerability discovered in one of the archiver or compressor implementations, and we have to rush to update the commons-compress library. And when we do this, we often find that commons-compress has added more strict file validation or has otherwise changed its behavior such that passing tests start to fail. So perhaps you can understand that we're very interested in reducing the impact of vulnerabilities by reducing the surface area of the library that we use. On that basis, I urge you to reconsider closing this PR. -- 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]
