Summary: | www-client/httrack bundles code from unzip | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Diego Elio Pettenò (RETIRED) <flameeyes> |
Component: | New packages | Assignee: | No maintainer - Look at https://wiki.gentoo.org/wiki/Project:Proxy_Maintainers if you want to take care of it <maintainer-needed> |
Status: | RESOLVED INVALID | ||
Severity: | QA | CC: | esigra, gef.kornflakes, roche |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 251464 |
Description
Diego Elio Pettenò (RETIRED)
2008-12-29 01:50:16 UTC
From ${WORKDIR}/httrack-3.43.7/src/minizip/ChangeLogUnzip: ---8<---------8<---------8<---------8<---------8<---------8<------ Change in 1.00: (10 sept 03) - rename to 1.00 - cosmetic code change ---8<---------8<---------8<---------8<---------8<---------8<------ This stuff is really old, but doesn't seem to share anything with unzip codebase; it uses zlib to implement unzip'ing capabilities. Silly me: --8<----8<----8<----8<----8<-- /* Decryption code comes from crypt.c by Info-ZIP but has been greatly reduced in terms of compatibility with older software. The following is from the original crypt.c. Code woven in by Terry Thorsen 1/2003. */ /* Copyright (c) 1990-2000 Info-ZIP. All rights reserved. This should probably be reported to upstream I do not think there is a vulnerability there ; the real compression/decompression is done through the system's zlib, not in this code. The unzip.c source in src/minizip is only a frontend to handle zip files (ie. get the entry in the central directory, and pipe the compressed data to zlib routines). I am not sure if we would need to unbundle it then No, there is no bug here. Can be closed safely. Thanks for feedback |