Por que uma distribuição Joomla ainda contém index.html em cada pasta?

Houve um PR para remover os arquivos index.html, mas nunca foi aplicado. Por que é que?

Eu sinto que este é um cenário "de ponta". Uma grande parte dos usuários do Joomla seria protegida e protegida sem esses arquivos, mas algumas pessoas executam o Joomla em um host mal configurado (e alguns em um host mal configurado que não permitirá que eles sejam reconfigurados), que exibiriam o conteúdo do diretório se o diretório fosse Requeridos. Este arquivo impede isso.

Em um nível pessoal, se você não precisa dos arquivos, é um inchaço desnecessário no cms e você pode removê-los.

No nível do CMS, acho que resolve um problema que pode ter grandes problemas de segurança com inchaço relativamente pequeno. (Os arquivos geralmente estão vazios ou contêm uma pequena linha de html.)

Não posso falar exatamente o motivo pelo qual o PR não foi aceito (já que nem tenho esse poder, muito menos conversar com as pessoas que o fazem); Eu acho que o benefício relativo à comunidade supera o inchaço.

Dito isto, há um método alternativo que ouvi falar em alguns eventos do Joomla sobre mover a maioria dos arquivos "para um nível superior". A idéia é obter todos os arquivos acima do public_htmldiretório para que os arquivos não possam ser acessados ​​diretamente. Você só deseja que o index.phparquivo, o .htaccessarquivo e as pastas imagese mediaestejam acessíveis na Web (para manter seu CSS, JS e imagens acessíveis).

Nesse ponto, você depende menos de uma configuração básica do servidor e pode garantir mais que os arquivos não serão acessados ​​de forma inadequada. Isso teria seus próprios problemas de configuração (já que agora precisamos acessar arquivos acima da nossa "raiz").

Em suma, não tenho certeza de que exista um plano mais infalível para manter as pessoas seguras sem muitos problemas do que usar index.htmlarquivos. Portanto, se eu estivesse lançando uma plataforma em geral, manteria os index.htmlarquivos.

O motivo de um index.html em cada pasta é protegê-lo para divulgar informações sobre o ambiente de hospedagem configurado incorretamente.

Se este é um problema real e o CMS deve considerar que é outra questão.

Que eu saiba, nunca houve um PR para isso. Existe um rastreador de recursos ( http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30192 ) que está "pronto para revisão". O patch existe apenas em uma ramificação e não é um PR. Portanto, essa é provavelmente a razão pela qual nunca foi mesclada.

Ou você está se referindo a outro PR?