Re: fetch extension - use local filename from content-dispositionheader (new diff)

Martin Cracauer wrote:
> Diff on
> http:/www.cons.org/tmp/freebsd-fetch-O2.diff
> 
> 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.

Colin Percival