[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bug-tar] [PATCH] Option to reject files similar to tarbombs
From: |
Paul Eggert |
Subject: |
Re: [Bug-tar] [PATCH] Option to reject files similar to tarbombs |
Date: |
Sat, 21 Sep 2013 08:28:59 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.0 |
A few comments:
It shouldn't be necessary to call malloc or to copy the
file name except in the special case where the first
top level is found.
Don't store string lengths in 'int'. Use size_t,
in case the string length exceeds INT_MAX.
Tar already prevents users from misusing "..", so
why does this code do that as well? How does it
interact with existing ".." code?
I don't understand why the code is worried about ".".
The documentation makes it sound like if the archive
contains names like "./foo1/x" and "./foo1/y", then
that's an error, because the "." is duplicated.
If that's intended, it should be stated more clearly.
The documentation should state how the new option interacts
with the --strip-components, --transform, and --absolute-file-names
options. That is, do we insist on a single top level before or
after these other options transform the file name? Also,
please look at all the other options and see if there are
other interactions that I've missed.
The option name should start with --one, not with --single,
by analogy with --one-file-system.