- Simple View Archive script for attachments
STATUS: Dropped/Rescinded.
Patches are not being accepted or reviewed by the
CoreTeam and there is also clearly noone crying out for this patch (personally I find it extremely useful) which leaves me with no incentive to fix the security issue related to this patch. For those interested in what this patch did, see the earlier page revision
here. For those interested in the patch itself, this has been zapped, however if you really want the patch, contact
me, or
go to
here and retrieve version 1.1 .
--
TWikiGuest - 31 Jul 2003
For the security fix: why not just use some flags to
unzip
that would automatically prevent any cloberring of files?
- -n never overwrite existing files This will ensure that no attack involving overrinding config files could succeed. However, it would make uploading new versions of files in place cumbersome, as you would have to delete them all one by one
- -j junk paths (do not make directories) This will force all files to be expansed in the current dir. This may be actually the desired behavior, to avoid peopl mistakenly creating subdirs
- -d extract files into exdir Will force decompression to happen into exdir, but will allow subdirs there
Note that the unzip I tested,
UnZip 5.50 of 17 February 2002, by Info-ZIP. Maintained by C. Spieler.
, automatically removes any "../" from start of file paths... see:
$ unzip foo.zip
Archive: foo.zip
warning: skipped "../" path component(s) in ../../../d/e/f/foo.txt
extracting: d/e/f/foo.txt
--
ColasNahaboo - 04 Aug 2003
Feel free to take development forward. The patch is in the earlier revisions of the code. I would appreciate the code being treated as licensed under the GPL and all the obligations that entails. I see no point in contributing code when the project does not adhere to GPL obligations with regard to patches & takes patches and says "docs required" when specifically told the patch is incomplete and not to take it. This is even more grating when there are (major) bugs that have fixes available that are ignored, and NEED patching. ( </gripe>, sorry)
Flattening directories is specifically not wanted - dumping in
HTML'ised source code trees is one aspect of use - the original aspect of use was in attaching photo galleries.(Which had subdirectories and so on) Personally I've found this very useful.
Incidentally gnu unzip also junks leading "../"'s, but there was valid report stating that there are versions out there that will happily junk other parts of the system. The -d flag would be in keeping with the modifications.
--
TWikiGuest - 04 Aug 2003
Updated progress fields with values from old manual "Nice to Have" table. Don't know how accurate they are.
--
SamHasler - 08 Sep 2004