| 2014-01-10 13:07:56 |
Alex Valavanis |
description |
I reported this on the dev mailing list ages ago but didn't get a reply. It's a possible security issue, so please could someone check before the 0.91release?
I found some unexpected behaviour with inkex-based extensions if a
non-existent SVG filename is specified.
To reproduce:
cd share/extensions
./gimp_xcf.py non-existent-file.svg
Expected behaviour:
* Script exits with an error message "Unable to open non-existent-file.svg"
Actual behaviour:
* Script silently falls back to reading from standard input, and
appears to freeze.
This appears to be caused by the fallback mechanism for obtaining data
streams in the Effect.parse() function in inkex.py. At the moment, it
does this:
1. Try to read file specified as a function argument e.g.,
my_effect.parse("this-file.svg)
2. If that file can't be opened, try to read the file specified in self.svg_file
3. If that file can't be opened, read from stdin
This could lead to some weirdness e.g.,
e = ProcessImportantData()
# Specify the wrong file name somewhere
e.svg_file = "wrong-input-data.svg"
# Later, try to read from the correct file, but with a typo
e.parse("correct-input-data-with-typo.svg_BORK")
# When we apply the effect, the
"correct-input-data-with-typo.svg_BORK" file doesn't exist, and the
script will silently fall back to using the wrong data file.
e.effect()
I have attached a patch that changes the behaviour so that the same
order of precedence is maintained, but the script will fail if the
specified file cannot be opened. I'm not the best Python programmer,
and I don't know the precise intended behaviour of the extensions
system, so please could someone review/comment? |
I reported this on the dev mailing list ages ago but didn't get a reply. It's a possible security issue, so please could someone check before the 0.91 release?
I found some unexpected behaviour with inkex-based extensions if a
non-existent SVG filename is specified.
To reproduce:
cd share/extensions
./gimp_xcf.py non-existent-file.svg
Expected behaviour:
* Script exits with an error message "Unable to open non-existent-file.svg"
Actual behaviour:
* Script silently falls back to reading from standard input, and
appears to freeze.
This appears to be caused by the fallback mechanism for obtaining data
streams in the Effect.parse() function in inkex.py. At the moment, it
does this:
1. Try to read file specified as a function argument e.g.,
my_effect.parse("this-file.svg)
2. If that file can't be opened, try to read the file specified in self.svg_file
3. If that file can't be opened, read from stdin
This could lead to some weirdness e.g.,
e = ProcessImportantData()
# Specify the wrong file name somewhere
e.svg_file = "wrong-input-data.svg"
# Later, try to read from the correct file, but with a typo
e.parse("correct-input-data-with-typo.svg_BORK")
# When we apply the effect, the
"correct-input-data-with-typo.svg_BORK" file doesn't exist, and the
script will silently fall back to using the wrong data file.
e.effect()
I have attached a patch that changes the behaviour so that the same
order of precedence is maintained, but the script will fail if the
specified file cannot be opened. I'm not the best Python programmer,
and I don't know the precise intended behaviour of the extensions
system, so please could someone review/comment? |
|
