Project

General

Profile

Evolution #3926

Remplacement de safehtml par le plug htmlpurifier ou autre

Added by Franck D over 2 years ago. Updated about 2 months ago.

Status:
Nouveau
Priority:
Normal
Assignee:
-
Category:
-
Target version:
Start date:
03/26/2017
Due date:
% Done:

0%

Resolution:

Description

Bonjour :-)
Je fais un ticket, sinon, il y aura oubli, la lib safehtml n'a plus de mise à jour dispo et n'est même plus trouvable, si je suis le lien qu'il y a https://zone.spip.org/trac/spip-zone/browser/_core_/plugins/safehtml/lib/safehtml/classes/safehtml.php#L14
Sur la zone, il y a un plug qui semble pouvoir résoudre le problème https://zone.spip.org/trac/spip-zone/browser/_plugins_/htmlpurifier après, je ne sais pas si il y a une autre lib qui serait mieux, mais en tout cas, il y a déjà une solution.
Je suppose que cela représente trop de boulot pour la 3.2, surtout que maintenant la version alpha est dispo, mais c'est peut-être possible pour la version 3.3 ?
Franck

spip-3.2.diff View - Patch pour SPIP 3.2 (1.44 KB) Guillaume Fahrner, 08/26/2018 08:41 AM

textwheel.diff View - Patch pour textwheel (2.73 KB) Guillaume Fahrner, 08/26/2018 08:41 AM

History

#1 Updated by Guillaume Fahrner about 1 year ago

Je me permet de rebondir sur ce ticket pour lancer la discussion, expliquer le travail déjà réalisé de mon coté et les problèmes rencontrés :

un constat : on rencontre souvent des contenus HTML devant passer dans safehtml() qui ne respecte pas à la lettre la spécification, quelques exemples :

Ces morceaux de code HTML seront systématiquement normalisé par htmlPurifier ; ce qui est une bonne chose.

Cela pose un problème d'incompatibilité avec le fonctionnement de la fonction echapper_html_suspect() https://core.spip.net/projects/spip/repository/entry/spip/ecrire/inc/texte_mini.php#L471 :

if (strlen(safehtml($texte)) !== strlen($texte)) {

Tous les contenus modifiés car normalisés se retrouveront donc encodés puis affichés :(

Plusieurs solutions :
  • changer la logique de la fonction echapper_html_suspect() pour faire confiance à safehtml()@htmlPurifier
  • normaliser tout ce qui est susceptible de passer à travers cette fonction pour éviter ces modifications et conserver cette logique

#2 Updated by Guillaume Fahrner about 1 year ago

Tant que j'y pense, un autre "problème" :

safehtml()@htmlPurifier transforme les entités HTML dans leur correspondance UTF8 (ce que safehtml() actuel ne fait pas), on se retrouve encore dans le cas avec des longeurs de chaines différentes et donc du texte HTML encodé puis affiché.

#3 Updated by RealET 🔸 about 1 year ago

Et on a donc une longueur différente dès qu'on a une apostrophe ' transformée en ’
Et c'est ici que ça se passe : https://core.spip.net/projects/spip/repository/entry/spip/ecrire/typographie/fr.php#L27

#4 Updated by Guillaume Fahrner about 1 year ago

Après avoir passé pas mal de temps à chercher une solution sécurisée ET fonctionnelle, voilà ce à quoi je suis arrivé sans tout casser ou devoir normaliser "100ans d'historique". La version de SPIP utilisé est SPIP 3.2.1 [23954]. En court : j'inverse la logique actuelle et je fais confiance à la sortie de safehtml du plugin Purifier :

j'ai modifié la fonction echapper_html_suspect() de inc/texte_mini.php, la fonction echappe_anti_xss() du plugin textwheel et 2 règles YAML et... c'est tout :

inc/texte_mini.php :

function echapper_html_suspect($texte, $strict=true) {
    if (!$texte
        or strpos($texte, '<') === false or strpos($texte, '=') === false) {
        return $texte;
    }
    // quand c'est du texte qui passe par propre on est plus coulant tant qu'il y a pas d'attribut du type onxxx=
    // car sinon on declenche sur les modeles ou ressources
    if (!$strict and
      (strpos($texte,'on') === false or !preg_match(",<\w+.*\bon\w+\s*=,UimsS", $texte))
      ){
        return $texte;
    }

    $safed_texte = safehtml($texte);
    if (strlen($safed_texte) !== strlen($texte)) {
        $texte = $safed_texte;
    }
    return $texte;
}

plugins-dist/textwheel/wheels/spip/echappe-js.php :

function echappe_anti_xss($match) {
    static $safehtml;
    if (!is_array($match) or !strlen($match[0])) {
        return "";
    }
    $texte = &$match[0];

    if ( 
    (strpos($texte, ":") !== false and preg_match(",(data|script)\s*:,iS", $texte) ) or 
        (stripos($texte, "on") !== false and preg_match(",\bon\w+\s*=,i", $texte) )
    ) {
        if (!isset($safehtml)) {
            $safehtml = charger_fonction('safehtml', 'inc', true);
        }
        $texte = $safehtml($texte);        
    }
    return $texte;
}

plugins-dist/textwheel/wheels/spip/echappe-js.yaml :

-
  if_str: "<script" 
  match: "{<script.*?($|</script.)}isS" 
  is_wheel: y
  replace:
    -
      type: all
      replace: htmlspecialchars
      is_callback: Y
    -
      type: all
      replace: nl2br
      is_callback: Y
    -
      type: all
      replace: "&lt;code class=\"echappe-js\"&gt;$0&lt;/code&gt;" 

-
  if_str: "&lt;" 
  match: "{&lt;[a-z]+.*?($|&gt;)}UisS" 
  is_callback: Y
  replace: echappe_anti_xss

plugins-dist/textwheel/wheels/spip/interdire-scripts.yaml :

securite-js:
  if_str: "<" 
  if_match: "/<[a-z]+/iS" 
  type: all
  replace: "echappe_js" 
  is_callback: Y

Pour le moment, du coté des effets de bord/choses cassées (nos fonctions sont remplis de spip_log() et on affiche le code impacté par safehtml() pour identifier rapidement les régressions) :
  • le changement de statut via le survol des puces (onmouseover inline) n'existe plus car l'attribut onmouseover est supprimé par htmlPurifier (rien de compliqué a fixer à mon sens, mieux cela oblige à développer (très) proprement, jme propose pour le patch si besoin)

Sinon pas de problème, on publie/modifie/supprime nos objets éditoriaux comme d'habitude, leur mise en forme n'a pas bougé, on install/update/supprime nos plugins, stats OK, config OK, etc, etc (cela fait déjà plusieurs jours que nous utilisons ces modifications).

Coté performance, la machine virtuelle est suivi via SNMP/librenms et on ne voit aucune différence d'utilisation CPU (merci le cache SPIP et OPcache) entre avant/après. D'autre part, htmlPurifier n'est pas appelé tout le temps, loin de là, on ne passe que "rarement" les conditions dans echappe_anti_xss().

Coté sécurité :

Coté publication :
Cela me semble risqué d'attendre une version majeure de SPIP avant de corriger ces problèmes de sécurité ; surtout que la transition peut se faire doucement en 3.2 avec une nouvelle version de textwheel et le remplacement (enfin) de plugin-dist/safehtml par htmlpurifier.

En espérant que ça aide et vous serve de base pour la suite.

g0uZ

#5 Updated by Guillaume Fahrner about 1 year ago

Content de voir que ce patch règle également des problèmes de mise en forme (je n'observe pas ce pb @home), je m'explique :

Dans mon post précédent, dans le contenu du fichier plugins-dist/textwheel/wheels/spip/echappe-js.yaml donné entre les balises

< pre>< code class="yaml">< / code>< / pre>

certains caractères "<" et ">" ont été encodé (mais pas d'autres (!) ) alors qu'à l'origine cette partie de mon post n'en contient aucun.

NB : essayez de mettre en forme avec <pre><code class="html"> la simple ligne de HTML donné dans ce post est ici impossible (les < > sont encodé alors que dans un < code >), une nouvelle fois je n'ai pas ce pb @home

#6 Updated by b b about 1 year ago

Merci g0uz, poste plutôt des patch au format diff, cela sera bien plus pratique à lire et à intégrer ;)

#7 Updated by cam.lafit - about 1 year ago

Salut

Tu peux aussi tester un PR sur git.spip.net/spip ou github

#8 Updated by Guillaume Fahrner about 1 year ago

Bonjour à tous,

ci-joint les patchs permettant de faire la bascule et d'avoir un mode parano fonctionnel, (il faut bien entendu activer le plugin HTMLPurifier) en attendant de l'avoir par défaut dans plugins-dist/safehtml/.

D'avance merci pour vos retours !

#9 Updated by cam.lafit - about 1 year ago

Bonjour

Merci pour le patch ::)

#10 Updated by cedric - about 1 year ago

  • Target version changed from 3.3 to 99 plus tard

On a mise à jour SafeHTML c'est reparti pour 10 ans :)

#11 Updated by Guillaume Fahrner 11 months ago

https://zone.spip.net/trac/spip-zone/browser/spip-zone/_plugins_/htmlpurifier

La version du trunk est à mon sens bonne pour être testée à partir de SPIP 3.2 (on l'utilise désormais depuis un bon moment sans problème hormis le onmouveover sur les puces de statuts qui est supprimé).

#12 Updated by cedric - 10 months ago

Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ?
on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ?

Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n'aurais pas vu ou auxquelles tu n'aurais pas pensé.

Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d'accord que cette écriture est obsolète et devrait être revue de toute façon, mais c'est donc un point à traiter dans le core le cas échéant

#13 Updated by Guillaume Fahrner 9 months ago

Sorry je n'avais pas vu ce message :

cedric - a écrit :

Depuis https://core.spip.net/projects/spip/repository/revisions/24131 le plugin HTMLPurifier est fonctionel sans nécessiter de patch dans le core ?

Malheureusement si : il reste une surcharge de la fonction propre() via inc/texte.php. Elle est utilisée pour réaliser la protection HTML via echappe_html() AVANT le 1er filtrage de sécurité via echapper_html_suspect(). Un deuxième est réalisé via echappe_retour_modeles($t, $interdire_script) ou $interdire_script est vrai en espacé privé ou si le mode parano actif et faux sinon. (Je n'ai pas su faire autrement, mais il y a peut être une astuce a trouver.)

Je ne sais pas si tu considères que c'est le core mais une surchage des règles YAML de textwheel est également réalisé afin que l'on envoi bien tout qui doit l'être dans les filtres de sécurité.

Donc non pas de modification du core nécessaire pour que le plugin fonctionne. A voir si ces surcharges mériterais une "intégration directe" future.

on est bon et on peut release tel quel en indiquant que le plugin htmlpurifier est disponible pour tests et se laisser le temps ?

A mon avis oui. Pour rappel : le mode parano est actuellement inutilisable avec l'actuel safehtml(). Du coup ça peut être une approche pour l'intégrer/le tester au fil de l'eau : commencé par les gens qui utilisent le mode parano en leur recommandant chaudement/forcant ce plugin.

Ci dessous la liste des plugins que j'utilise sans problème hors textwheel/todo (cf https://core.spip.net/issues/4254) avec htmlPurifier :

Abonnements 3.3.6 - stable
Agenda 3.26.0 - stable
API de vérification 1.8.1 - stable
API Prix 0.1.16 - dev
Article PDF 1.0.10 - stable
Autorité 0.10.20 - stable
Banque&paiement 3.6.7 - stable
Cache Cool 0.5.4 - stable
Challenge Hacking 1.0.0 - stable
Champs Extras 3.11.7 - stable
Chatbox 1.0.5 - stable
Coloration Code 99 - stable
Commandes 1.15.5 - stable
Compositions 3.7.3 - stable
Crayons 1.26.18 - stable
CTF all the day 1.0.0 - stable
Facteur 3.6.2 - stable
Formulaire de contact avancé 0.16.5 - stable
Frimousses 1.5.1 - stable
GIS 4.44.24 - stable
HTML Purifier 5.0.0.1 - test
iCalendar 0.4.5 - test
Import ics 4.4.3 - stable
Imprimer document 0.2.2 - stable
LangOnet 1.4.6 - stable
MailShot 1.27.3 - stable
MailSubscribers 2.11.3 - stable
Markdown 1.0.2 - test
Messagerie 3.1.8 - test
Mini Calendrier 2.4.1 - stable
Mot de passe dès l’inscription 1.0.19 - stable
Newsletters 1.6.0 - stable
Nombres de visiteurs connectés 0.2.3 - stable
NoSPAM 1.5.18 - stable
Notation 2.4.2 - test
Notifications 3.6.8 - stable
Notifications avancées 0.4.2 - test
Pages 1.3.7 - stable
Pre & Code 99 - test
Saisies pour formulaires 3.11.1 - stable
Social tags 1.1.1 - stable
SPIP Bonux 3.4.6 - stable
Tip A Friend 1.6.9 - stable
Todo 2.2.1 - stable
Traduction entre rubriques 3.1.3 - stable
YAML 1.5.4 - stable

Je pense que si on doit intégrer le plugin ça sera sur la version dev 3.3, pas sur la version stable, et ça va demander de prendre le temps de voir toutes les modifs et les impacts éventuels que tu n'aurais pas vu ou auxquelles tu n'aurais pas pensé.

Clairement je pense me faire insulter :-) Je suis prêt ^^ Plus sérieusement il faut absolument tester/restester/reretester. J'ai tenté de faire au mieux mais je ne peux pas revoir tout le code HTML généré par les plugins... Au moindre écart de conformité HTML ca ne passera pas. Le bug https://core.spip.net/issues/4254 en est un bon exemple : avec htmlpurifier l'élément <table> est supprimé ; avec "safehtml() standard" le code invalide est conservé et c'est le navigateur qui va corriger.

Il faut voir les bons cotés: cela force les bonnes pratiques, met SPIP au plus haut niveau du standard (Drupal fait moins bien), aide a identifier des bugs et ce qui passe dans propre() sera obligatoirement valide. C'est aussi a terme moins de problèmes d'injection XSS a traiter pour la team.

Sur la fonction de survol des logos le sujet reste ouvert ? On est en effet d'accord que cette écriture est obsolète et devrait être revue de toute façon, mais c'est donc un point à traiter dans le core le cas échéant

Euh je comprend pas, faut-il intégrer le patch des puces de statut dans ce plugin ? Je pensais plus coder le truc """proprement""" avec un JS dans le <head> directement dans /prive/. A décolérer complètement à mon sens.

Encore merci pour le temps que tu y passes :)

#14 Updated by b b 8 months ago

C'est aussi a terme moins de problèmes d'injection XSS a traiter pour la team

\o/ ho oui ça ferait du bien :)

#15 Updated by jluc - 6 months ago

Le plugin htmlpurifier a été installé pour test sur programmer.spip.net. En mode normal pour l'instant a priori (pas "parano").
- Tout semble bien se passer.
- Il n'y a pas de problème pour les actions sur les puces
- il n'y a pas de problème avec le logo de survol qui fonctionne bien avec les squelettes actuels lorsque la config "Utiliser les logos de survol" est activée
- Mieux : les problèmes signalés dans #4306 https://core.spip.net/issues/4306 et dûs à safehtml sont tous réglés.

Peut être ces problèmes sont sensés se manifester seulement en mode parano ?

#16 Updated by Guillaume Fahrner 6 months ago

jluc - a écrit :

Le plugin htmlpurifier a été installé pour test sur programmer.spip.net. En mode normal pour l'instant a priori (pas "parano").
- Tout semble bien se passer.
- Il n'y a pas de problème pour les actions sur les puces
- il n'y a pas de problème avec le logo de survol qui fonctionne bien avec les squelettes actuels lorsque la config "Utiliser les logos de survol" est activée
- Mieux : les problèmes signalés dans #4306 https://core.spip.net/issues/4306 et dûs à safehtml sont tous réglés.

Peut être ces problèmes sont sensés se manifester seulement en mode parano ?

Euh clairement les puces permettant un changement de statut rapide ne sont plus fonctionnelles (attribut onmouse* supprimés) coté privé, y compris sans mode parano (j'ai testé), une fois le plugin activé. Qu'on se comprenne bien : les puces de statut sont la, mais plus rien ne se passe quand on passe la souris dessus.

#17 Updated by jluc - 6 months ago

Ben si justement les puces marchent bien sur programmer avec htmlpurifier activé.

Tout semblait bien marcher mais pas sur une page les chevrons sont échappés dans une balise cadre dans le public, aussi bien avec htmlpurifier que sans semble t il : https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 mais pas dans le privé où le rendu est parfait : https://programmer.spip.net/ecrire/?exec=article&id_article=128

#18 Updated by jluc - 6 months ago

Par contre le même article passe bien dans le carnet de contrib https://contrib.spip.net/test-safehtml

#19 Updated by Guillaume Fahrner 5 months ago

jluc - a écrit :

Ben si justement les puces marchent bien sur programmer avec htmlpurifier activé.

Encore une fois, ce n'est pas normal #PUCE_STATUT passe dans typo/propre et l'attribut onmonseouver se retrouve filtré (comportement attendu), il y a peut être un traitement spécifique sur programmer.

Tout semblait bien marcher mais pas sur une page les chevrons sont échappés dans une balise cadre dans le public, aussi bien avec htmlpurifier que sans semble t il : https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 mais pas dans le privé où le rendu est parfait : https://programmer.spip.net/ecrire/?exec=article&id_article=128

C'est "normal" parce que j'imagine que le mode parano est inactif, donc pas de filtrage coté public. Il doit être actif pour avoir l'équivalent coté public. Ce bug n'a a mon sens aucun rapport avec le plugin puisque

"aussi bien avec htmlpurifier que sans".

Et dans le carnet j'imagine que c'est filtré tout le temps "cause mode wiki".

Le problème doit venir d'un filtrage textwheel ou du core appliqué sur < et > pour des raisons de sécurité mais en dehors de safehtml()/du mode parano : il n'y pas de filtrage mais un peu quand même (sécurité

J'ai testé @home (spip 3.2 à jour avec htmlPurifier) et pas de soucis pour afficher https://programmer.spip.net/spip.php?page=ticket&id_ticket=348 coté privé ou public.

#20 Updated by cam.lafit - 5 months ago

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi

#21 Updated by RealET 🔸 5 months ago

cam.lafit - a écrit :

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi

Et plus récent dans sa dernière version que HTMLPurifier (dont la page qui compare les différentes libs ne compare qu'avec une très vieille version).

Et en plus, ça marche avec composer : http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/composer_usage.htm

Par contre, aucune des 2 libs n'est sur un repository affichant des diffs

#22 Updated by Guillaume Fahrner 5 months ago

cam.lafit - a écrit :

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi

Imo c'est vraiment tout ce qu'il faut éviter, pour rappel : ce n'est pas possible d'imaginer construire une libraire de filtrage à base de regexp/preg_match & co. L'utilisation d'un parser XML est obligatoire pour espérer faire le travail le plus correctement possible.

#23 Updated by Guillaume Fahrner 5 months ago

RealET 🔸 a écrit :

cam.lafit - a écrit :

Salut

Pour note : je viens tomber sur ce script (maintenu) pour nettoyer simplement le html
http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/

Utiliser chez glpi si j'ai bien suivi

Et plus récent dans sa dernière version que HTMLPurifier (dont la page qui compare les différentes libs ne compare qu'avec une très vieille version).

Et en plus, ça marche avec composer : http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/composer_usage.htm

Par contre, aucune des 2 libs n'est sur un repository affichant des diffs

Les différences sont claires, il suffit d'aller voir le code ^^' D'ailleurs ça se paye cash, je prend le premier motif d'injection sur https://html5sec.org/ et je test sur http://www.bioinformatics.org/phplabware/internal_utilities/htmLawed/htmLawedTest.php (avec safe=1 dans les settings) :

Input code :
<form id="test"></form><button form="test" formaction="javascript:alert(1)">X</button>

Output code :
<form id="test" action="action"></form><button form="test" formaction="javascript:alert(1)">X</button>

J'ai ri :] C'est pas plutôt htmFFFLawed cette librairie ?! ;-)

#24 Updated by Guillaume Fahrner 5 months ago

  • Target version changed from 99 plus tard to 3.3

Est ce qu'on peut maintenant le mettre dans la version "spip 3.3 dev" en remplaçement de safehtml ? Puis on le testerai jusqu'à la release de la 3.4 si pas de pb par exemple.

Au final ce qu'il faut tester ce n'est pas tant la nouvelle librairie (qui doit quand même faire son taf) que les surcharges de textwheel (règles YAML, fonctions de filtrage associées et la modification dans propre()@inc/texte.php qui inverse l'ordre de echappe_html() et echappe_html_suspect().

Pour rappel : ça n'impacte que le /ecrire/ pour les sites sans mode parano.

Si des propriétaire de Spip avec $filtrer_javascript=-1 peuvent tester ce serait bien.

#25 Updated by Guillaume Fahrner 5 months ago

Parce que j'avais un peu oublié cet aspect: le mode parano est cassé/inefficient depuis très (très très ?) longtemps https://core.spip.net/projects/spip/repository/revisions/24064 (et j'ai l'impression que personne ne s'en ai jamais plaint alors que c'était pourtant très impactant lorsque filtrage indispensable).

Autant dire que le remplacement de safehtml par htmlpurifier ne devrait gêner aucun utilisateur (y en a t il seulement ?) du mode parano qui :

- avant ce patch, n'avait pas un système effectif niveau sécurité
- après ce patch, se retrouve avec une mise en forme par propre() non fonctionnelle coté public (coté privé typo() utilise le bon ordre avec echappe_html() puis echappe_html_suspect().

Avec le mode parano inactif, le filtrage n'est donc appliqué que dans /ecrire/ (et sur certains éléments spécifique à protéger coté public, les forums par exemple). Beaucoup de tests/vérification ont déjà) été faites sur l'espace privé 3.2, et (hors puce) aucun problème de mise en forme a été identifié ; c'est même le contraire, beaucoup de problème de mise en forme réglés (le filtrage par liste noire dans textwheel introduisant des bugs).

Il peux rester d'éventuels bugs dans /ecrire/ liés a des plugins qui générerait du code HTML non conforme mais cela me semble peu probable (bcp moins que coté public) et doit de toute façon être corrigé.

Le site https://programmer.spip.net/ utilise htmlPurifier pour test (mode parano inactif) : pas de problème identifié dans l'espace privé :)))

#26 Updated by Franck D 3 months ago

Hello :-)
Ne ne faudrait-il pas le mettre dans la 3.3, sortir la version en alpha1 et suivant les retours prendre une décision une fois pour toute ?
Car là, nous n'avons que https://programmer.spip.net qui permet de faire des tests

Surtout que à l'annonce de spip 3.3 alpha1, il est toujours possible de mettre en avant qu'il peut encore y avoir du changement d'ici la sortie de la version "stable"

#27 Updated by Guillaume Fahrner 3 months ago

Autre endroit pour faire des tests : https://www.root-me.org/ avec un spip3.2 uptodate, (les "joueurs" font déjà bcp de tests ^^)

Sinon oui, je plussoie pour l'intégrer en 3.3 alpha et voir si ça coince encore a certains endroits.

#28 Updated by RealET 🔸 3 months ago

À ce propos Guillaume, est-ce que tu pourrais mettre à jour la version HTML5 pour prendre en compte https://zone.spip.net/trac/spip-zone/changeset/115979/spip-zone

Merci

#29 Updated by Guillaume Fahrner about 2 months ago

RealET 🔸 a écrit :

À ce propos Guillaume, est-ce que tu pourrais mettre à jour la version HTML5 pour prendre en compte https://zone.spip.net/trac/spip-zone/changeset/115979/spip-zone

Merci

Ok a l'occase j'essaye de faire ca (j'ai tenté rapidement sans succès :p). A priori il s'agit d'améliorer la compat PHP 7.3, je suis actuellement en 7.2 sans problème.

Also available in: Atom PDF