Utilisation de modules "non couverts par la politique de conseil en sécurité de Drupal"
Je voudrais utiliser un module Drupal 7 qui "n'est pas couvert par la politique d'avis de sécurité de Drupal", en particulier le module Champs conditionnels .
Cela me permettrait de faire exactement ce dont j'ai besoin. Il semble que ce module soit assez activement utilisé et entretenu, mais je ne sais pas à quel point je devrais être inquiet à propos de l'utilisation d'un module pour lequel je ne recevrai pas de mises à jour si un problème de sécurité devait survenir.
Aucun conseil? Est-ce que coder quelque chose comme ça (en utilisant hook_form_alter et states) est moi-même une approche plus sûre?
Selon le Processus d'avis de sécurité et politique d'autorisations , les modules qui ont un statut alpha, bêta ou rc (relancer le candidat) ne sont pas couverts par cette politique, et les avis de sécurité ne seront pas signalés pour ces projets. Au moment de la rédaction de cet article, Champs conditionnels a des versions recommandées pour Drupal 7 et 8 qui sont toutes deux au stade "alpha". Même sans avis de sécurité, vous pouvez toujours choisir être averti lorsque le module est mis à jour.
Étant donné que les versions de module et leur statut sont arbitrairement attribués par les responsables de projet, vous seul pouvez juger si vous devez utiliser un module marqué comme n'étant pas couvert par la politique d'avis de sécurité de Drupal. Le module "alpha" d'un responsable serait une version "1.0" pour un autre responsable.
Vous devez examiner la crédibilité du responsable, l'historique sur Drupal.org, la popularité du projet et la vitesse à laquelle les problèmes sont résolus ou traités. De nombreux sites populaires et publics utilisent des modules "beta" ou autres.
Coder votre propre module pour dupliquer les fonctionnalités d'un module qui existe déjà semble plus susceptible d'introduire des failles de sécurité qui ne peuvent être diagnostiquées ou corrigées que par une seule personne: vous. L'utilisation d'un module "alpha" avec un responsable compétent et une communauté active d'utilisateurs semble bien plus conseillée.
Soyez prudent dans "seulement" en utilisant le avis de sécurité . Au lieu de cela, vous voudrez peut-être considérer de nombreux autres critères pour vous aider à prendre des décisions. Comme je l'ai documenté dans (ce que j'appelle) tableaux de bord de maintenance . Dans ce cas, ils concernent les modules de cartographie, mais vous pouvez bien sûr les appliquer à n'importe quel ensemble de modules.
Ce sont l'OMI les critères que vous devriez également considérer:
- Nombre de bogues ouverts
- Aucun élément RTBC
- Dernières validations
- Docu communautaire
- Prise en charge de 2 versions principales
- Version DEV pour D8
- Nombre de committers
- Tests simples ou tests unitaires
- Test automatisé activé
- Téléchargements/installations
- Utilisateurs contributeurs dans les validations