On Donnerstag, 18. August 2016 15:34:12 CEST Giuseppe Scrivano wrote: > Hi, > > Tim Rühsen <tim.rueh...@gmx.de> writes: > > Please review / test this patch. > > > > Please check the 'Reported-by' in the commit message and if you got a CVE > > number, please report for inclusion into the commit message (and/or the > > code). > > > > Regards, Tim > > > > On Mittwoch, 17. August 2016 10:40:35 CEST Dawid Golunski wrote: > >> Random file name + .part extension on temporary files would already be > >> good improvement (even if still stored within the same directory) and > >> help prevent the exploitation. > > I still think we should used a fixed extension, not a random file name.
You mean *only* a fixed extension without random part ? With very long file names (length >= max length of supported by filesystem) we need a variant of the current file name shorten algorithm. IMO, this is unneeded code inflation. > If wget crashes or the process is terminated for any reason, these files > will be left around. Yes, but easy to see / find using 'wget_*.part' pattern. > With a deterministic name, at least we can recover > from what was left. With -A/-R and --spider only (HTML | CSS) files are affected. Which are very seldom large enough that downloading again would hurt. With --recursive, all those files have to be redownloaded anyways. We could use a simple 6 or 8 hex digit hash of the original file instead of the random part to have a deterministic file name. Is something like that what you think of ? > IMO, it is enough to open these files with rw only for the user and not > add any extra complexity. It is not wget responsibility to take care of > a misconfigured server that allows to execute random files fetched from > http/ftp. To cite myself :) "But there is also non-obvious wget behavior in creating those (temp) files in the filesystem." The Wget docs just don't make clear that these files come into existence for a while. Of course we could amend the docs and lean back... but it still is not an intuitive behavior and I fear people might trap into that pit. And we could easily prevent it with some lines of code... Regards, Tim
signature.asc
Description: This is a digitally signed message part.