-
Notifications
You must be signed in to change notification settings - Fork 29
Does it sanitize
reserved name like CON or COM1 on Windows?
#14
Comments
Not currently handled, but would be a great (and simple) addition. It looks like any name starting with those values and a period are also invalid. |
If It should probably stated in the documentation whether the function is expected to be secure (there may be even advisories about it in this case) or not. Transforming a hostile string into a filename (secure to use, but still mostly representing the string in question) is a hard-ish task. Does it chop off too long filename by the way? |
The intent wasn't security, but to make sure that e.g. somebody developing on Linux wouldn't accidentally use path names that fail on Windows. We call |
Then either the scope and intent should be enlarged to include uses for security (e.g. the name is 100% guranteed to be "no tricks"), or phrase like "the function should not be used for security, to sanitize hostile user input" or "it is possible that Maybe the latter better suits the purpose of this library, as the former may require building and maintaining blacklists of names per various platforms and may be more (not |
Agreed; I can add a clarification to the docs. It definitely isn't intended to be used on user input, but programmer input - to create a directory structure for their app data in the right place. |
A secure filename sanitizer may worth a separate crate. It may be full of heuristics and tweaks (like "no unicode + abbreviate + supplement with a short hash" or "please make a 8.3 filename") |
Clicking at
[src]
in the documentation does not show any special handling of things like(source)
Note that it can also be complexier like
aux.txt
Is it because of online documentation isn't for windows or it is not handled?
The text was updated successfully, but these errors were encountered: