#716841 special characters should be escaped when used in templates

#716841#5
Date:
2013-05-29 23:57:00 UTC
From:
To:
Dear Maintainer,

While installing the cacti package I got asked for a password for the cacti database. I had the misfortune of typing a password containing a double-quote. This resulted in cacti not starting due to an obvious syntax error in '/etc/cacti/debian.php':

$database_password = "prickly"cacti";

Escaping the double-quote at least got the Cacti website to come up. I did not test further with that password however.

#716841#10
Date:
2013-07-13 13:22:01 UTC
From:
To:
clone 710331 -1
reassign -1 dbconfig-common
retitle -1 special characters should be escaped when used in templates
block 710331 by -1
retitle 710331 cacti: no special character handling in configuration
thanks

Cacti uses dbconfig-common to configure the cacti database connection.
However, as far as I can tell dbconfig-common doesn't do anything to
ensure proper handling of special characters in strings. If I have a
password for my database containing special characters, I get them all
as they were, making the procedure impossible to use with templates.

E.g. the following line ends up exactly like it is:
x" '\
making either " or ' as string delimiters (or no delimiters) in php or
sh not doing the right thing. Of course the proper escaping depends on
the language of the template, e.g. for sh the above line could be
escaped as:
'x" '\''\' or with a lot more care to take all variations into account:
"x\" '\\"
for php, it needs to be something like
'x" \'\\' or "x\" '\\"
and probably for other languages even something different.

Of course, the template in cacti should not contain the quotes anymore
when dbconfig-common escapes the strings properly. So I clone the bug
accordingly.

#716841#25
Date:
2014-10-10 10:07:32 UTC
From:
To:
Hi all,

The logic to dbconfig-generate-include in the dbconfig-common source is
slightly flawed [1] in the sense that it escapes all variable depending
on the language in case the dbconfig-common templates are used, but
forgets to do this language specific when a package template is used. As
I don't think there is a watertight check possible to determine what
language the variables should be escaped for (and e.g. in case of php/sh
it also depends on how the strings are quoted (' vs ")) I propose to
extend the format from "template" to "template | phptemplate |
shtemplate | perltemplate | cpptemplate" and use the right escape
algorithm depending on the selected format. I propose to keep "template"
as-is but let it generate a warning.

Objections? Other ideas or solutions?

Paul

[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=716841