<p>MathJax nécessite une "politique de sécurité du contenu" non sécurisée</p>

unsafe eval est un gros problème pour moi aussi. Très bientôt, chrome forcera toutes les extensions à adopter une politique de sécurité du contenu qui interdit l'utilisation de eval . Nous essayons actuellement de mettre à jour Readium pour nous conformer à cela, mais nous ne pouvons pas l'utiliser et utiliser MathJax

+1

Merci les gars. Nous allons l'examiner.

Juste une mise à jour préliminaire. Il semble possible de résoudre certains des problèmes assez tôt (espérons-le assez pour le magasin Chrome). Cependant, nous ne savons pas comment les performances en souffriront – ce qui, comme vous pouvez le deviner, pourrait être mauvais. Nous vous tiendrons au courant lorsque @dpvc pourra examiner cela plus en détail et peut-être créer des branches expérimentales.

Si vous avez d'autres commentaires, questions et suggestions concernant un code spécifique, veuillez nous en informer.

J'ai passé un peu de temps à m'y pencher moi-même. Il semble que vous deviez arrêter avec l'optimisation prématurée. L'évaluation d'une chaîne n'est PAS plus rapide que la création d'une fermeture.

De plus, vous ne devriez pas exécuter eval() sur chaque page qui charge Mathjax juste pour vérifier si vous pouvez exécuter eval() . Fondamentalement, cela doit aller.

Les appels new Function() ne sont pas pour la vitesse mais pour la mémoire. Le new Function() ne crée pas de fermeture et ne conserve donc pas la portée locale. Comme c'est au cœur du modèle de programmation orienté objet et qu'il y a beaucoup d'objets utilisés, cela pourrait avoir un impact sur l'utilisation de la mémoire. Je n'ai fait aucun test de cela dans les navigateurs récents.

Quant à l'utilisation de eval , MathJax l'utilise pour gérer ses blocs de configuration en ligne, et cela ne peut pas être facilement remplacé à ce stade. Ainsi, une version "sûre" de MathJax devrait utiliser des fichiers de configuration externes (ce qui ne devrait pas poser de problème et est probablement plus conforme à la politique de sécurité de toute façon). L'appel eval auquel vous faites référence ne sert pas à déterminer si eval peut être exécuté, mais à déterminer s'il s'exécute dans l'espace de noms global (ce qui n'est pas le cas dans tous les navigateurs). Je suis conscient que cela devrait être supprimé pour une version qui fonctionnerait avec vos besoins de sécurité.

Ce n'est pas comme ça que les fermetures fonctionnent en javascript. Vous ne vous accrochez pas à tout ce qui concerne la portée locale ; vous ne capturez que les éléments utilisés par votre fonction. Votre fonction CONSTRUCTOR n'utilise rien de la portée locale, il n'y a aucun coût pour créer la fermeture. Il s'agit d'une optimisation prématurée pour un problème qui n'a jamais existé.

En ce qui concerne la chose eval , mon point est que vous ne devriez pas exécuter de code sur une page si vous n'en avez pas besoin, surtout si ce code utilise eval() non sécurisé. Vous n'utilisez cette fonction EVAL que si Mathjax a été inclus dans la configuration en ligne, donc n'exécutez pas le test jusqu'à ce que vous en ayez besoin. Mais vraiment, pourquoi diable la configuration doit-elle être un code exécutable. C'est vraiment juste un morceau de JSON qui est passé à la fonction. Pourquoi ne pas simplement passer le JSON, l'analyser et demander à MathJAX d'appeler la fonction ?

Ce n'est pas comme ça que les fermetures fonctionnent en javascript. Vous ne vous accrochez pas à tout ce qui concerne la portée locale ; vous ne capturez que les éléments utilisés par votre fonction.

Je ne pense pas que les choses soient aussi claires que cela. Premièrement, ce n'était _pas_ le cas en 2008 lorsque cette partie du code a été écrite. Je viens de faire des tests ce matin qui semblent confirmer que les versions de Safari, Firefox, Opera et IE en jeu à l'époque fonctionnaient toutes comme je l'ai décrit (la chaîne de portée complète a été conservée dans une fermeture, quelles que soient les variables utilisées ). Le site qui est ma référence pour cela semble être en panne ce matin (était hier), donc je ne peux pas vérifier les détails, mais je me souviens que cela faisait partie de la spécification ECMAScript 262.

Les versions actuelles de Safari, Chrome, Firefox et IE semblent fonctionner comme vous le décrivez, donc quelque part depuis lors, les choses ont changé. Il semble que Safari 4, Firefox 3.6 et IE9 aient été à l'origine du changement ; Je n'ai pas d'anciennes versions de Chrome à tester, donc je ne connais pas l'historique. IE8 a l'ancien comportement, et Opera 12 le fait toujours. Je n'ai pas vérifié les appareils mobiles. Certains de ces navigateurs sont sur la liste de support de MathJax, c'est donc toujours un problème que nous devons considérer pour MathJax en général. Bien sûr, je suis sûr que quelque chose peut être élaboré pour vos besoins.

Comme pour les données JSON, le bloc de configuration peut être plus qu'un simple appel MathJax.Hub.Config() . Par exemple, vous pouvez installer des écouteurs d'événements ou ajouter des fonctions au jax d'entrée TeX pour implémenter des commandes supplémentaires, etc. Ceux-ci ne peuvent pas faire partie des données JSON car ils incluent du code exécutable. Cette fonctionnalité n'est pas toujours utilisée, mais elle est certainement utilisée par les sites Web réels. De plus, tous les navigateurs cibles n'ont pas de bibliothèque JSON intégrée, et il faudrait donc des bibliothèques supplémentaires pour effectuer l'analyse. (Certainement pas insurmontable, mais plus de code à télécharger.)

+1 pour avoir changé cela, afin que (entre autres) Github autorise à nouveau MathJax dans leurs wikis.

@ketch avez-vous une référence pour Github faisant une déclaration à cet égard ? Je ne vois pas comment ce problème affecte la sécurité de Github Wiki.

@pkra Je ne sais pas avec certitude que c'est la cause, mais je le crois. J'ai été amené à cela par les commentaires sur cette page:

http://stackoverflow.com/questions/16889421/how-to-insert-javascript-to-enable-mathjax-on-github-wiki-pages

Et voir

https://github.com/blog/1477-content-security-policy

Je crois que le support de MathJax a disparu en même temps qu'ils ont implémenté la fonctionnalité CSP.

Merci, c'est intéressant. Je ne suis pas sûr que les deux soient liés mais qui sait - l'équipe github n'a jamais expliqué publiquement pourquoi ils ont supprimé MathJax. Il serait regrettable que quelque chose qui n'est en fait pas un problème pour leur configuration en ait été la raison.

+1 pour se conformer au CSP.

+1

J'ai lu ce fil et je l'ai trouvé très informatif et assez impartial. Je vais revendiquer qu'ils [github] empêcheraient quelque chose comme exec, CSP sur les questions de sécurité et de ne pas le permettre.

En plus d'être mystifié par cet échantillon de code et votre tradition informatique mythique des versions passées, je le trouve néanmoins très intéressant et je considère qu'une fonctionnalité devrait être disponible pour son utilisation continue, même si elle ne devrait pas interférer avec l'heureux chemin d'utilisation de MathJAX dans le monde concerné par la sécurité.

Au fait, j'ai envoyé un e-mail au support Github pour expliquer pourquoi ils avaient abandonné MathJax. Voici la réponse :

CSP était l'une des raisons. D'autres raisons comprenaient des problèmes de performances et une maintenance difficile. Nous pourrions envisager de le rajouter si nous éliminions les raisons qui nous poussent à le supprimer, mais je ne peux pas le promettre.

Merci @ketch , c'est bon à savoir.

@dpvc devrions-nous ajouter cela au prochain jalon ?

:+1:

@pkra , j'avais l'intention de l'ajouter. Je n'étais pas encore descendu aussi bas numériquement dans la liste.

@dpvc à droite. Je me demandais surtout si la résolution de ce problème nécessiterait des modifications importantes (en particulier les configurations en ligne), c'est-à-dire forcer un saut de version.

Les modifications que nous avons apportées pour permettre la configuration via la variable MathJax devraient permettre de l'inclure sans saut. Je suis presque sûr que je peux le faire avec une compatibilité descendante et sans avoir à créer une version "sûre" séparée de MathJax.js. Bien sûr, quelque chose pourrait apparaître pendant le développement qui jetterait une clé à molette dans les travaux ; rien de tout cela n'est encore écrit ou testé.

+1 pour sécuriser MathJax. Dommage de ne pas pouvoir utiliser cette jolie bibliothèque en production pour des raisons de sécurité.

Des avancées sur ce sujet ? J'essaie d'injecter par programme MathJax dans des pages avec une extension Chrome, et je frappe sinon un mur de briques au moins un mur décemment solide. Comme décrit dans emichael/textthings#4, mon plus gros problème est maintenant avec MathJax.js:265 . J'ai pu éliminer les appels à

new Function()

assez facilement en les transformant en fermetures comme décrit ci-dessus, mais je n'ai aucune idée de comment se déplacer en utilisant eval ou un script en ligne.

EDIT : J'ai fini par donner à l'utilisateur la possibilité d'ajouter unsafe-eval et unsafe-inline au CSP, mais un correctif à long terme pour amener MathJax à un CSP sûr serait bien. :+1:

@emichael , nous prévoyons d'inclure les modifications dans la prochaine version (prévue pour le mois prochain), mais je ne les ai pas encore faites. L'une des raisons est que je n'ai pas examiné comment vous testez réellement cela (comment configurer l'environnement qui l'exige). Si vous pouviez me suggérer où chercher ou ce que pourrait être un environnement de test minimal, cela aiderait.

En outre, l'erreur concernant eval est-elle celle qui se produit au moment de l'exécution ou au moment de la compilation ? Autrement dit, cela se produit-il si MathJax.js inclut simplement un appel eval, même s'il n'est jamais utilisé, ou cela se produit-il uniquement lorsque eval est réellement tenté ? Ma lecture de la spécification suggère qu'il devrait s'agir d'une erreur d'exécution, ce qui améliorerait les choses pour moi, mais je pensais que vous connaissiez peut-être la réponse.

Si vous avez un serveur de test, vous pouvez simplement définir Content-Security-Policy dans les en-têtes de réponse. Assurez-vous simplement que script-src n'inclut pas 'unsafe-eval' ou 'unsafe-inline' (GitHub lui-même en est un bon exemple). Si vous ne le faites pas, vous pouvez utiliser une extension Chrome très minimale pour injecter vous-même les en-têtes.

C'est une erreur d'exécution.

Merci. Je vais voir ce que je peux faire.

La commande eval n'est utilisée que pour traiter les blocs de configuration en ligne (et il y en a un initial pour tester la façon dont les variables globales sont gérées dans ce cas). La première peut être différée jusqu'à ce qu'une configuration en ligne soit utilisée, et si vous évitez d'utiliser une configuration en ligne, cela devrait s'en occuper. Dans la v2.3, nous avons ajouté une nouvelle façon de faire la configuration en ligne sans eval (en préparation de la résolution de ce problème), vous pouvez donc toujours inclure la configuration MathJax dans les fichiers HTML sans déclencher l'appel eval.

OK, j'ai fait un patch qui supprime les appels new Function() et eval() . Il est basé sur la dernière branche de développement, mais les modifications répertoriées dans f220993 devraient également pouvoir être apportées à la copie principale de MathJax.js , si vous en avez besoin. Vous devez autoriser les styles en ligne (il n'y a vraiment pas moyen de contourner cela). Il existe également une référence de police à about:blank afin que MathJax puisse tester la réponse à une police manquante (sans avoir à créer un accès réseau), vous pouvez donc ajouter about: à font-src aussi. Une fois que j'ai changé ces deux, cette copie de MathJax a fonctionné sans accroc.

Agréable! Je peux voir pourquoi vous avez vraiment besoin 'unsafe-inline' pour les styles.

En ce qui concerne l'autorisation script-src 'unsafe-inline' , si je vous comprends bien, les scripts ne sont intégrés que lorsque l'utilisateur inclut la configuration MathJax en ligne pour commencer. Ce serait bien, puisque tout pourrait encore fonctionner sans 'unsafe-inline' dans script-src . Il devrait être mentionné dans les docs, cependant.

Votre compréhension des scripts en ligne est correcte. Vous n'avez pas besoin script-src 'unsafe-inline' sauf si vous utilisez des blocs de configuration en ligne, que vous n'avez pas besoin d'utiliser. Vous pouvez utiliser soit un fichier de configuration MathJax local (ajouté au config= ) ou vous pouvez utiliser un fichier de script normal qui définit la variable MathJax sur un objet que vous passeriez normalement à MathJax.Hub.Config() et chargez ce fichier _avant_ votre script qui charge MathJax.js. Par exemple, mettez

var MathJax = {
  tex2jax: {
    inlineMath: [['$','$'],['\\(','\\)']],
    procesEscapes: true
  }
};

dans un fichier appelé mathjax-config.js puis

<script src="mathjax-config.js"></script>
<script src="http://cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS_HTML"></script>

J'espère que cela prend soin de vos exigences.

C'est vrai. Merci pour la réparation rapide!!

Il y en a ici qui diraient que ce n'était pas si rapide (le problème est ouvert depuis deux ans !), mais je l'avais marqué pour la prochaine version, et je m'y mettais de toute façon, donc votre commentaire est venu à le moment opportun.

=> Fusionné.

alors quelqu'un a-t-il déjà demandé à github d'autoriser mathjax? il n'est toujours pas possible d'écrire un fichier dotjs qui me permet d'écrire tex dans les problèmes de github afin de rendre avec mathjax ...

(l'exemple ici - http://stackoverflow.com/questions/16889421/how-to-insert-javascript-to-enable-mathjax-on-github-wiki-pages - échoue.)

Bonjour,

J'héberge actuellement un site jekyll sur les pages github et suit cet article , et j'ai ajouté ce qui suit à mon fichier inclus :

<script type="text/javascript"
  src="//cdn.mathjax.org/mathjax/latest/MathJax.js?config=TeX-AMS-MML_HTMLorMML">
</script>

Ce qui est censé fonctionner avec https ou http. Cependant, lors du chargement de mon blog sur un navigateur avec https partout, il semble foiré jusqu'à ce que vous cliquiez pour autoriser le script non sécurisé. Comment puis-je réparer cela?

@silky rien de spécifique AFAWK. Le côté client est peu probable, je pense, mais MathJax-node pourrait fournir une alternative productive.

@diego898 Les questions générales conviennent mieux à http://groups.google.com/forum/#!forum/mathjax -users ; incluez toujours un lien vers une page en direct, les spécificités du navigateur et du système d'exploitation, etc. Merci.

@pkra Je comprends que je n'étais tout simplement pas sûr s'il s'agissait d'un bogue lié à ce problème ou d'un problème de configuration de ma part

@ diego898 pas de problème. Ce que vous décrivez ne semble pas lié à ce problème.

Je vois toujours ce problème. Voir https://github.com/mathjax/MathJax/issues/1988.

@kaushalmodi , voir mon commentaire ci-dessus sur la façon d'éviter le problème, ou mon commentaire sur le problème auquel vous faites référence. Vous devez modifier la façon dont vous configurez MathJax si vous utilisez un CSP qui limite l'exécution des scripts.

(2) dans le problème d'origine a-t-il déjà été résolu ? Il semble que mathjax v3 insère toujours