Hello again!

I wanted to thank you guys for your input! It is greatly appreciated. :)

Wish you well.

Best,
Benedikt

Am 19.05.17 um 13:16 schrieb Stefan Bodewig:
> On 2017-05-18, Benedikt Tröster wrote:
> 
>> Hi Stefan,
> 
>> thanks a lot for your detailed answer! That explained most of my concerns.
>> However here are some things I have questions about:
> 
>> Am 18.05.17 um 18:17 schrieb Stefan Bodewig:
>>> Compress will give you the path as it is contained inside the
>>> archive but if an aplication blindly accepts an absolute path, it is the
>>> applications fault.
> 
>> How would one receive the path from the archive? Would getName() contain
>> a full path (if given in the archive) such as "/etc/passwd"? or will it
>> always contain the file name "passwd"?
> 
> If the format stored the file name as /etc/passwd getName() would return
> /etc/passwd. This may be the case for tar for example, but other formats
> like ZIP don't allow leading slashes.
> 
>> When protecting against ZIP bombs I guess you would do a size check
>> before unpacking via getSize(), right? You said this is not available
>> for every file type, is there documentation for which archive type it is
>> not available?
> 
> Not in a single place. But rather scattered. From the top of my head you
> should have the size information for all archiving formats except for
> ZIP, and if your used ZipFile instead of ZipArchiveInputStream the
> uncompressed size will always be there as well. ZipArchiveInputStream
> may know the size before extracting the stream only under certain
> conditions depending on the compression format and how the archive has
> been created.
> 
> Most of the compression formats don't know the uncompresed size.
> 
>> If a ZIP file contains a ZIP file itself, this will not automatically be
>> "resolved" by the library, right? As a dev you'd have start a new
>> decompression process on the ArchiveEntry containing the second level
>> archive, right?
> 
> This is correct.
> 
>> Is it possible to determine if an Entry is actually a Symlink?
> 
> Most formats don't support symlinks at all. Those who do have
> corresponding isXXX methods on the *ArchiveEntry subclasses.
> 
> If your application doesn't look at those flags, it is going to treat
> the entries as plain files - and usually obtain the target name as the
> content. This won't turn the file into a symlink by itself.
> 
> Stefan
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [email protected]
> For additional commands, e-mail: [email protected]
> 

-- 
Benedikt Tröster

ERNW GmbH - Carl-Bosch-Str. 4 - 69115 Heidelberg - www.ernw.de - Mobile
+49 151 16227792 - Fax 6221 419008

Handelsregister Mannheim: HRB 337135
Geschaeftsfuehrer: Enno Rey

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to