<p>MathJax requer "Política de Segurança de Conteúdo" insegura</p>

avaliação insegura é um grande problema para mim também. Muito em breve, o Chrome forçará todas as extensões a adotar uma política de segurança de conteúdo que proíbe o uso de eval . No momento, estamos tentando atualizar o Readium para cumprir isso, mas não podemos usá-lo e usar o MathJax

+1

Obrigado rapazes. Nós vamos investigar isso.

Apenas uma atualização preliminar. Parece possível corrigir alguns dos problemas em breve (espero o suficiente para a loja do Chrome). No entanto, não temos certeza de como o desempenho será afetado - o que, como você pode imaginar, pode ser ruim. Manteremos você atualizado quando @dpvc puder analisar isso com mais detalhes e talvez criar algumas ramificações experimentais.

Se você tiver comentários adicionais, perguntas e sugestões sobre códigos específicos, por favor nos avise.

Passei um pouco de tempo olhando para mim mesmo. Parece que vocês precisam parar com a otimização prematura. Avaliar uma string NÃO é mais rápido do que criar um encerramento.

Além disso, você não deve executar eval() em todas as páginas que carregam o Mathjax apenas para verificar se você pode executar eval() . Basicamente, isso precisa ir.

As chamadas new Function() não são para velocidade, mas para memória. O new Function() não cria um encerramento e, portanto, não mantém o escopo local. Como isso está no centro do modelo de programação orientada a objetos e há muitos objetos em uso, isso pode ter um impacto no uso da memória. Eu não fiz nenhum teste disso em navegadores recentes.

Quanto ao uso de eval , o MathJax o usa para lidar com seus blocos de configuração em linha, e isso não pode ser facilmente substituído neste momento. Portanto, uma versão "segura" do MathJax precisaria usar arquivos de configuração externos (o que não deve ser um problema, e provavelmente está mais de acordo com a política de segurança de qualquer maneira). A chamada eval a que você se refere não é para determinar se eval pode ser executado, mas para determinar se ele é executado no namespace global (o que não é o caso em todos os navegadores). Estou ciente de que isso precisaria ser removido para uma versão que funcionasse com suas necessidades de segurança.

Não é assim que os closures funcionam em javascript. Você não se apega a tudo no âmbito local; você apenas captura coisas que sua função usa. Sua função CONSTRUCTOR não usa nada do escopo local, não há custo para criar o encerramento. Esta é uma otimização prematura para um problema que nunca existiu.

No que diz respeito ao eval , meu ponto é que você não deve executar código em uma página se não precisar, especialmente se esse código usar eval() inseguro. Você só usa essa função EVAL se o Mathjax tiver sido incluído na configuração in-line, portanto, não execute o teste até que seja necessário. Mas realmente, por que diabos a configuração tem que ser um código executável. É realmente apenas um pedaço de JSON que é passado para funcionar. Por que não apenas passar o JSON, analisá-lo e fazer com que o MathJAX chame a função?

Não é assim que os closures funcionam em javascript. Você não se apega a tudo no âmbito local; você apenas captura coisas que sua função usa.

Não acho que as coisas sejam tão claras assim. Primeiro, esse _não_ era o caso em 2008, quando essa parte do código foi escrita. Acabei de executar testes esta manhã que parecem confirmar que as versões do Safari, Firefox, Opera e IE em jogo no momento funcionaram da maneira que descrevi (a cadeia de escopo completa foi mantida em um encerramento, independentemente das variáveis ​​usadas ). O site que é minha referência para isso parece estar fora do ar esta manhã (estava no ar ontem), então não posso verificar detalhes, mas minha lembrança é que isso fazia parte da especificação ECMAScript 262.

As versões atuais do Safari, Chrome, Firefox e IE parecem funcionar como você descreve, então em algum lugar desde então as coisas mudaram. Parece que Safari 4, Firefox 3.6 e IE9 foram onde a mudança ocorreu; Não tenho versões antigas do Chrome para testar, então não conheço o histórico de lá. O IE8 tem o comportamento mais antigo e o Opera 12 ainda tem. Eu não verifiquei dispositivos móveis. Alguns desses navegadores estão na lista de suporte do MathJax, então ainda é um problema que devemos considerar para o MathJax em geral. Claro, tenho certeza que algo pode ser elaborado para suas necessidades.

Quanto aos dados JSON, o bloco de configuração pode ser mais do que apenas uma chamada MathJax.Hub.Config() . Por exemplo, você pode instalar ouvintes de eventos ou adicionar funções ao jax de entrada do TeX para implementar comandos adicionais e assim por diante. Eles não podem fazer parte dos dados JSON porque incluem código executável. Esse recurso nem sempre é usado, mas certamente _está_ sendo usado por sites reais. Além disso, nem todos os navegadores de destino têm uma biblioteca JSON integrada e, portanto, seria necessário haver bibliotecas adicionais para fazer a análise. (Certamente não intransponível, mas mais código para download.)

+1 para alterar isso, para que (entre outras coisas) o Github permita o MathJax em seus wikis novamente.

@ketch você tem uma referência para o Github fazer uma declaração a esse respeito? Não vejo como esse problema afeta a segurança do Github Wiki.

@pkra Não tenho certeza de que essa seja a causa, mas acredito que seja assim. Fui levado a isso pelos comentários nesta página:

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

E veja

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

Acredito que o suporte ao MathJax desapareceu ao mesmo tempo em que eles implementaram o recurso CSP.

Obrigado, isso é interessante. Não tenho certeza se os dois estão relacionados, mas quem sabe - a equipe do github nunca discutiu publicamente por que eles removeram o MathJax. Seria lamentável se algo que não é realmente um problema para a configuração deles fosse o motivo.

+1 por cumprir com CSP.

+1

Eu li este tópico e achei muito informativo e bastante imparcial. Vou afirmar que eles [github] impediriam algo como exec, CSP sobre questões de segurança e não permitiriam.

Além de ficar perplexo com aquele exemplo de código e seu mítico conhecimento de computador de versões anteriores, acho muito interessante mesmo assim e assumo a posição de que um recurso deve ser disponibilizado para seu uso contínuo, embora não deva interferir no feliz caminho de usar o MathJAX no mundo preocupado com a segurança.

A propósito, enviei um e-mail ao suporte do Github sobre por que eles abandonaram o MathJax. Aqui está a resposta:

CSP foi um dos motivos. Outras razões incluíam problemas de desempenho e manutenção difícil. Podemos considerar adicioná-lo de volta se eliminarmos os motivos que nos levaram a removê-lo, mas não posso prometer isso.

Obrigado @ketch , é bom saber.

@dpvc devemos adicionar isso ao próximo marco?

:+1:

@pkra , eu estava planejando adicioná-lo. Só não tinha chegado tão longe numericamente na lista ainda.

@dpvc certo. Eu estava pensando principalmente se consertar isso exigiria mudanças significativas (especialmente configurações inline do wrt), ou seja, forçar um salto de versão.

As alterações que fizemos para permitir a configuração através da variável MathJax devem permitir incluí-la sem saltos. Tenho certeza de que posso fazer isso com compatibilidade com versões anteriores e sem ter que criar uma versão "segura" separada do MathJax.js. Claro, algo poderia aparecer durante o desenvolvimento que colocaria uma chave de macaco nos trabalhos; nada disso foi escrito ou testado ainda.

+1 para tornar o MathJax seguro. É uma pena não poder usar esta bela biblioteca em produção devido a questões de segurança.

Algum progresso nesta questão? Estou tentando injetar o MathJax programaticamente em páginas com uma extensão do Chrome e estou atingindo, se não uma parede de tijolos, pelo menos uma parede decentemente sólida. Conforme descrito em emichael/textthings#4, meu maior problema agora é com MathJax.js:265 . Consegui eliminar as chamadas para

new Function()

muito facilmente, transformando-os em encerramentos conforme descrito acima, mas não tenho ideia de como usar eval ou um script embutido.

EDIT: Acabei dando ao usuário a opção de adicionar unsafe-eval e unsafe-inline ao CSP, mas uma correção de longo prazo para levar o MathJax a um CSP seguro seria bom. :+1:

@emichael , estamos planejando incluir as mudanças na próxima versão (planejada para o próximo mês), mas ainda não as fiz. Uma razão é que eu não examinei como você realmente testa isso (como configurar o ambiente que exige isso). Se você pudesse me dar uma sugestão de onde procurar ou qual seria um ambiente de teste mínimo, isso ajudaria.

Além disso, o erro sobre eval ocorre em tempo de execução ou em tempo de compilação? Ou seja, ocorre se MathJax.js simplesmente inclui uma chamada eval, mesmo que nunca seja usada, ou acontece apenas quando eval realmente é tentado? Minha leitura da especificação sugere que deve ser um erro de tempo de execução, o que melhoraria as coisas para mim, mas pensei que você pudesse saber a resposta.

Se você tiver um servidor de teste, basta definir Content-Security-Policy nos cabeçalhos de resposta. Apenas certifique-se de que script-src não inclua 'unsafe-eval' ou 'unsafe-inline' (o próprio GitHub é um bom exemplo). Caso contrário, você pode usar uma extensão mínima do Chrome para injetar os cabeçalhos você mesmo.

É um erro de tempo de execução.

Obrigado. Verei o que posso fazer.

O comando eval é usado apenas para processar os blocos de configuração in-line (e existe um inicial para testar como as variáveis ​​globais são tratadas nesse caso). A inicial pode ser adiada até que uma configuração em linha seja usada e, se você evitar usar a configuração em linha, isso deve resolver isso. Na v2.3 adicionamos uma nova maneira de fazer a configuração in-line sem eval (em preparação para resolver este problema), então você ainda pode incluir a configuração MathJax dentro dos arquivos HTML sem acionar a chamada eval.

OK, eu fiz um patch que remove as chamadas new Function() e eval() . Ele é baseado na última ramificação de desenvolvimento, mas as alterações listadas em f220993 também devem poder ser feitas na cópia mestre de MathJax.js , se você precisar fazer isso. Você precisa permitir estilos in-line (não há como contornar isso). Há também uma referência de fonte para about:blank para que o MathJax possa testar a resposta a uma fonte ausente (sem ter que fazer um acesso à rede), então você pode querer adicionar about: a font-src também. Uma vez que eu mudei esses dois, esta cópia do MathJax funcionou sem problemas.

Agradável! Eu posso ver porque você definitivamente precisa de 'unsafe-inline' para estilos.

No que diz respeito à permissão script-src 'unsafe-inline' , se entendi corretamente, os scripts só são alinhados quando o usuário inclui a configuração MathJax inline para começar. Isso seria bom, já que tudo ainda poderia funcionar sem 'unsafe-inline' em script-src . Deve ser mencionado nos documentos, no entanto.

Seu entendimento sobre scripts embutidos está correto. Você não precisa de script-src 'unsafe-inline' a menos que esteja usando blocos de configuração in-line, que você não precisa usar. Você pode usar um arquivo de configuração local do MathJax (adicionado ao config= ) ou pode usar um arquivo de script normal que define a variável MathJax para um objeto que você normalmente passaria para MathJax.Hub.Config() e carregue esse arquivo _antes_ de seu script que carrega MathJax.js. Por exemplo, coloque

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

em um arquivo chamado mathjax-config.js e então

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

Espero que isso atenda às suas necessidades.

Isso sim. Obrigado pela solução rápida!!

Há alguns aqui que diriam que não foi tão rápido (a edição está aberta há dois anos!), mas eu a marquei para o próximo lançamento e estava começando a trabalhar de qualquer maneira, então seu comentário veio em o momento apropriado.

=> Combinado.

então alguém já pediu ao github para permitir o mathjax? ainda não é possível escrever um arquivo dotjs que me permita escrever tex em problemas do github para renderizar com mathjax ...

(o exemplo aqui - http://stackoverflow.com/questions/16889421/how-to-insert-javascript-to-enable-mathjax-on-github-wiki-pages - falha.)

Olá,

Atualmente, estou hospedando um site jekyll nas páginas do github e seguindo este artigo e adicionei o seguinte ao meu arquivo de inclusão:

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

Que deve funcionar com https ou http. No entanto, ao carregar meu blog em um navegador com https em todos os lugares, parece confuso até você clicar para permitir script inseguro. Como posso consertar isso?

@silky nada específico AFAWK. O lado do cliente é improvável, eu acho, mas o MathJax-node pode fornecer uma alternativa produtiva.

@diego898 Perguntas gerais se encaixam melhor em http://groups.google.com/forum/#!forum/mathjax -users; sempre inclua um link para uma página ativa, detalhes do navegador e do sistema operacional etc. Obrigado.

@pkra Entendo que não tinha certeza se era um bug relacionado a esse problema ou um problema de configuração da minha parte

@ diego898 sem problemas. O que você descreve não parece estar relacionado a esse problema.

Ainda estou vendo esse problema. Consulte https://github.com/mathjax/MathJax/issues/1988.

@kaushalmodi , veja meu comentário acima sobre como evitar o problema ou meu comentário sobre o problema ao qual você está vinculado. Você precisa alterar a forma como configura o MathJax se estiver usando um CSP que restringe a execução de scripts.

(2) no problema original já foi resolvido? Parece que o mathjax v3 ainda insere