fetch extension - use local filename from
content-dispositionheader (new diff)
cperciva at freebsd.org
Fri Dec 30 10:48:45 PST 2005
Martin Cracauer wrote:
> Diff on
> When discussing, keep in mind that the user has to explicity give the
> -O option (there is no environment variable to permanently turn this
> on) and that the implications of the -O options are very clear and
> simple. And that the main use of this is for folks who have to go
> through a gazillion of Bugzilla attachments all name
> "customer-errlog.20051220" etc, and there is no other way to download
> them in a name-preserving manner than interactively opening them in
> Mozilla and saving them.
> Before we randomize the list even more I would say I'd like to hear
> from the security officer if there is concern left.
Ask and ye shall receive. :-)
I must say that I still have some concerns about this. In general,
creating a file with a server-specified name is a very easy way to
open up security problems; aside from the already-mentioned problems
of overwriting important system files or creating dot-files, I can
very easily imagine a script which calls fetch(1) being in the current
directory and being overwritten maliciously.
I also wonder why having an option for fetch(1) to create files with
server-specified names is necessary. It seems to me that the best way
to provide the functionality you want is to add a "-H headername"
option which instructs fetch(1) to print out the value (if any) of the
"headername" HTTP header. Then you could have a script download the
file you want to a safe location, look at the Content-Disposition
header, sanity-check it, and rename the file as appropriate.
More information about the freebsd-current