News for hackers. Stuff that matters.
Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by Bromskloss on Sunday May 29, 2016 @06:58PM (#11798611)
> why are pipes even being allowed in the file name in the first place?

Why not? It's a perfectly legitimate (printable) character. The filesystem can't know that one shell or another will come along and use it (and several other characters) for special purposes.

I go the opposite way and rather question why slashes aren't allowed. Non-printable characters, though, I think we could do without them. Put differently, I think it makes sense to let filenames consist of characters, rather than of bytes.

Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by Sir_Cmpwn on Sunday May 29, 2016 @08:46PM (#11798983)
>I go the opposite way and rather question why slashes aren't allowed.

You mean aside from the obvious reason that a slash is the path seperator?

Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by Bromskloss on Sunday May 29, 2016 @09:17PM (#11799055)
I'm thinking that a path should be a list of directory names (and possibly a file name at the end), not tied to any particular way of representing this list. In some contexts, such as in a shell, concatenating the directory names, with slashes between them, ("/home/bromskloss/hello.txt") might be the way to represent it. In that case, a slash in the name would have to be escaped. Other times, such as in code, an array might be cleaner (["home", "bromskloss", "hello.txt"]).
Re:GraphicsMagick and ImageMagick popen() shell vulnerabilit... by Sephr on Sunday May 29, 2016 @09:06PM (#11799030)
There are filesystems that let filenames consist of any Unicode characters. Tag-based filesystems do not need to rely on special cased path separators, as long as they provide a sufficient UI and API for file management and interaction.