Réponses:
J'ai l'impression que c'est un scénario de "cas limite". Une grande partie des utilisateurs de Joomla seraient sécurisés et sûrs sans ces fichiers, mais certaines personnes exécutent Joomla sur un hôte mal configuré (et d'autres sur un hôte mal configuré qui ne les laissera pas reconfigurer) qui afficherait le contenu du répertoire si le répertoire était demandé. Ce fichier empêche cela.
Sur le plan personnel, si vous n'avez pas besoin des fichiers, c'est un gonflement inutile dans les cms et vous pouvez les supprimer.
Au niveau du CMS, je pense que cela résout un problème qui peut avoir des problèmes de sécurité majeurs avec un ballonnement relativement mineur. (Les fichiers sont généralement vides ou contiennent une petite ligne de code html.)
Je ne peux pas parler de la raison exacte pour laquelle le PR n'a pas été accepté (puisque je n'ai même pas ce pouvoir, encore moins discuter avec les gens qui en ont); Je pense que le bénéfice relatif pour la communauté l'emporte sur le ballonnement.
Cela étant dit, j'ai entendu parler d'une autre méthode lors de quelques événements Joomla pour déplacer la majorité des fichiers "à un niveau supérieur". L'idée est d'obtenir tous les fichiers au-dessus du public_htmlrépertoire afin que les fichiers ne soient pas accessibles directement. Vous ne voudriez que le index.phpfichier, le .htaccessfichier et les dossiers imageset mediaaccessibles sur le Web (pour garder votre CSS, JS et vos images accessibles.)
À ce stade, vous comptez moins sur une configuration de serveur de base et vous pouvez davantage garantir que les fichiers ne seront pas accédés de manière inappropriée. Cela aurait ses propres problèmes de configuration (puisque maintenant nous devons accéder aux fichiers au-dessus de notre "racine").
Dans l'ensemble, je ne suis pas sûr qu'il existe un plan plus infaillible pour sécuriser les gens sans beaucoup de problèmes que d'utiliser des index.htmlfichiers. Donc, si je publiais une plateforme en général, je m'en tiendrais aux index.htmlfichiers.
La raison d'un index.html dans chaque dossier est de le protéger pour divulguer des informations sur l'environnement d'hébergement mal configuré.
Si c'est un vrai problème et que les cms doivent considérer que c'est une autre question.
À ma connaissance, il n'y a jamais eu de RP pour ça. Il existe un outil de suivi des fonctionnalités ( http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=30192 ) qui est "prêt à être examiné". Le patch n'existe que dans une branche et n'est pas un PR. C'est donc probablement la raison pour laquelle il n'a jamais été fusionné.
Ou faites-vous référence à un autre PR?