Cli: [QUESTION] --ignore-scripts pour la sécurité uniquement ?

Comment npm ferait-il la différence entre les scripts sécurisés et non sécurisés ?

S'il pouvait le faire, pourquoi un paramètre serait-il nécessaire pour ignorer les paramètres non sécurisés ?

Il ne ferait pas la différence entre les scripts sécurisés et non sécurisés.
Cela autoriserait simplement les scripts lors de l'utilisation d'une commande npm sur le module supérieur.
Étant donné que le propriétaire n'est pas un tiers, on peut supposer qu'il est digne de confiance.

Gotcha, c'est logique. Je n'ai jamais défini cela comme paramètre de configuration global, mais casser npm run aurait été assez frustrant.

J'ai défini ignore-scripts sur true et j'ai été déçu de découvrir que npm start sur mon projet a complètement cessé de fonctionner sans aucune sortie.

J'aimerais que les scripts ignorent la sécurité, en particulier pour désactiver les scripts de post-installation, mais pouvoir exécuter mes propres scripts et des scripts tiers, uniquement explicitement avec npm start ou npm run. Devoir ajouter --ignore-scripts à chaque fois que je veux ajouter un paquet est assez fragile car il suffit de l'oublier une seule fois et vous pouvez être silencieusement compromis par une dépendance tierce profondément cachée.

En général, je crois fermement que le comportement par défaut de npm cli est dangereux et doit être modifié d'une manière ou d'une autre. Par exemple, npm pourrait m'inviter avant d'exécuter un script, à moins qu'il ne soit explicitement demandé ou mis sur liste blanche.

Mon employeur n'est pas disposé à introduire npm dans la pile avec le comportement actuel, donc ma seule option pour le moment semble reposer sur la configuration de l'indicateur ignore-scripts sur chaque poste de travail.

De plus, je voudrais noter que je suis conscient que l'ajout d'une dépendance a des conséquences de sécurité plus larges que les scripts, mais les scripts à mon avis sont particulièrement dangereux pour plusieurs raisons. Avoir un paquet malveillant dans votre projet est aussi mauvais que cela puisse paraître, mais au moins il peut y avoir un peu plus de temps avant qu'il ne puisse exécuter sa charge utile, il y a donc un léger espoir qu'il puisse être détecté à temps. De plus, les développeurs sont plus susceptibles de voir une récupération supplémentaire dans devtools ou quelque chose du genre lors du débogage de leur code par rapport à la charge utile s'exécutant directement sur leurs ordinateurs et couvrant ses traces. Un seul projet avec un package malveillant pourrait potentiellement compromettre l'ensemble de l'IP de l'entreprise, même sans rapport avec le projet. Il peut être difficile d'identifier une brèche à la source du problème ou même de détecter une brèche.

Désolé si je soutiens ce problème spécifique avec mon débordement de pensées paranoïaques, mais je pense que les responsables de npm et la communauté devraient avoir une conversation sérieuse sur ce sujet. Commencez peut-être à réfléchir à la façon dont JavaScript et npm s'intègrent dans des choses comme la Bytecode Alliance .