Si la fonction est appelée par une action en CRON, le test de la ligne 393 fait que le contenu du fichier SVG passe à travers safehtml() et cela modifie le contenu du fichier SVG. Par exemple, voici ce que ça donne pour un fichier SVG généré par Inkscape :
Le <? au tout début du fichier le rend illisible par un navigateur ou un éditeur de fichier SVG. Si je modifie la source du document et que je corrige ce <? le fichier SVG semble correct.
Du coup, un rédacteur qui télécharge un fichier SVG sur un site SPIP se retrouve avec un fichier corrompu.
Qu'est-ce qu'on peut faire pour corriger ça ? Faut-il corriger safehtml() ou traite_svg() ?
SafeHtml au moins voire les deux. Car non seulement il y a le "<" au début, mais en plus tous les attributs en "xmlns:..." ont été virés par SafeHtml, à cause de la ligne 127 de extensions/safehtml/lib/safehtml/classes/safehtml.php qui devrait accepter tous les attributs commençant par xml, pas seulement xml:lang.
Pour le "<" initial, il faut enlever la premiere ligne du contenu du fichier avant analyse par Safehtml et ensuite la remettre. C'est indifférent de le faire au niveau de Safehtml ou au niveau de traite_svg. Je pencherai pour la première solution car d'autres formats XML sont susceptibles un jour d'être soumis à ça.
SafeHtml au moins voire les deux. Car non seulement il y a le "<" au début, mais en plus tous les attributs en "xmlns:..." ont été virés par SafeHtml, à cause de la ligne 127 de extensions/safehtml/lib/safehtml/classes/safehtml.php qui devrait accepter tous les attributs commençant par xml, pas seulement xml:lang.
Pour ça le patch suivant semble faire l'affaire (?).
spip/extensions/safehtml/lib/safehtml/classes/safehtml.php
@@ -87,7 +87,7 @@
var $attributes = array('dynsrc', 'id', 'name', );
- var $attributesNS = array('xml:lang', );
+ var $attributesNS = '/^xml/';
function SafeHTML() {
@@ -124,7 +124,7 @@
continue;
}
if (!preg_match("/^[a-z0-9-]+$/i", $name)) {
- if (!in_array($name, $this->attributesNS))
+ if (!preg_match($this->attributesNS, $name))
{
continue;
}
Pour le "<" initial, il faut enlever la premiere ligne du contenu du fichier avant analyse par Safehtml et ensuite la remettre. C'est indifférent de le faire au niveau de Safehtml ou au niveau de traite_svg. Je pencherai pour la première solution car d'autres formats XML sont susceptibles un jour d'être soumis à ça.
Je pense ajouter ça dans safehtml() de inc/texte.php mais je me pose la question suivante : n'est-ce pas "dangereux" d'exclure la première ligne des traitements de safehtml ? Un petit malin ne pourrait-il pas tenter de coller du code pas "sympa" dans cette première ligne ?
Après avoir regardé plus en détail je vois que c'est interdire_scripts() qui transforme le < en "<".