Skip Menu |
 

This queue is for tickets about the Archive-Zip CPAN distribution.

Report information
The Basics
Id: 22933
Status: open
Priority: 0/
Queue: Archive-Zip

People
Owner: Nobody in particular
Requestors: japh [...] tirwhan.org
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.18
Fixed in: (no value)

Attachments


Subject: Properly extract symbolic links (proposed patch included)
Download (untitled) / with headers
text/plain 823b
Archives which are created with the "zip -y" command (thus preserving symbolic links, as opposed to following them and including the destination file) are not currently (version 1.18) properly extracted by Archive::Zip. Instead of the symbolic link, Archive::Zip creates a file that contains the name of the link destination. The attached patch fixes this problem. However, it would probably be a good idea to also include a configuration directive (which defaults to off), enabling the extraction of symlinks, otherwise users can unknowingly create security holes when unzipping malicious archives. I wasn't sure how best to add this to the existing interface, which is why I didn't add it in the patch. Also, the patch probably breaks on Window systems (don't have one so can't test that :-)
Subject: Archive-Zip-1.18-symlink.patch
--- Archive-Zip-1.18/lib/Archive/Zip/Member.pm 2006-10-25 14:18:49.000000000 +0200 +++ Archive-Zip-new/lib/Archive/Zip/Member.pm 2006-11-10 11:57:08.000000000 +0100 @@ -22,6 +22,7 @@ use Compress::Zlib qw( Z_OK Z_STREAM_END MAX_WBITS ); use File::Path; use File::Basename; +use Fcntl ':mode'; use constant ZIPFILEMEMBERCLASS => 'Archive::Zip::ZipFileMember'; use constant NEWFILEMEMBERCLASS => 'Archive::Zip::NewFileMember'; @@ -379,10 +380,20 @@ return $bit == IFA_BINARY_FILE; } +sub isSymbolicLink { + my $self = shift; + return S_ISLNK($self->unixFileAttributes()); +} + sub extractToFileNamed { my $self = shift; my $name = shift; # local FS name return _error("encryption unsupported") if $self->isEncrypted(); + if ($self->isSymbolicLink()) { + mkpath( dirname($name) ); + my $symlink_exists = eval { symlink($self->contents(),$name); 1 }; + return $symlink_exists ? AZ_OK : AZ_ERROR; + } mkpath( dirname($name) ); # croaks on error my ( $status, $fh ) = _newFileHandle( $name, 'w' ); return _ioError("Can't open file $name for write") unless $status;
Download (untitled) / with headers
text/plain 108b
Trying to clean up some RT tickets here. Is this still an issue? Does the latest revision fix the problem?


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.