On all OSes, this is a behaviour difference:
QUrl("file:///a%2Fb").toLocalFile()
And on Windows, this changes too.
QUrl("file:///c:\\autoexec.bat").toLocalFile()
Previously, the first would return "/a/b" on all OSes, and the second a file of
"c:\autoexec.bat" on Windows (on Unix, it will continue to return
"/c:\\autoexec.bat").
But starting with Qt 6.13, both of those cases will return an empty string, as
if the URL did not contain a local file URL. That is in spite of both
isLocalFile() and isValid() returning true. If there's interest, I can make
isValid() return false and error() explain why.
This is done to prevent a hidden path separator allowing access to a file that
was not meant to be accessed. QUrl::resolved() and other URL-manipulating
functions operate *exclusively* on forward slashes, not backslashes and not
slashes encoded as %2F.
URLs created using QUrl::fromLocalFile are not affected because:
a) file names are never percent encoded, so they never produce %2F
b) file names on Windows are converted to forward slashes
Therefore, this problem can only happen with URLs constructed from their
encoded form at some point. This may have been done accidentally by your end-
users, but it might be coming from untrusted data your applications are
parsing, which is why this check is here.
And one more case:
QUrl("file:///a%00b").toLocalFile()
This will also be rejected, as no file name in any OS can contain the NUL
character. This one, however, can be created using fromLocalFile(), but if
your code is operating on valid file names, it should never happen. For this
one, the this is either deliberately malicious data or a bug somewhere that
corrupted a file name.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Principal Engineer - Intel DCG - Platform & Sys. Eng.
smime.p7s
Description: S/MIME cryptographic signature
-- Development mailing list [email protected] https://lists.qt-project.org/listinfo/development
