Evaluar un plugin ajeno
Antes de añadir uno: qué mirar, qué señales avisan, y por qué un plugin es una dependencia con más consecuencias que una librería normal.
Qué mirar
Los tres primeros son específicos de los plugins y los tres se leen en el mismo sitio: el directorio de permisos, que es la ficha técnica real.
Las señales de aviso
Cuatro cosas que deberían hacer parar:
- Un solo permiso que lo abarca todo. Nivel 68.1: obliga a conceder todo.
- Comandos que aceptan rutas, URLs u órdenes sin ámbito. Es la superficie del nivel 14.4 en código ajeno, y no puedes arreglarla.
- Sin declaración de plataformas soportadas, si tú soportas varias.
- Y un árbol de dependencias desproporcionado para lo que hace.
La segunda es la más seria: un plugin que expone un comando genérico de ejecutar procesos, o de leer cualquier fichero, te obliga a confiar en que quien lo escribió pensó en la fase V — y no puedes comprobarlo sin leer su código.
Plugin oficial, de la comunidad, o propio
Y una observación: los plugins suelen ser pequeños, así que leer su código entero es viable — a diferencia de una librería grande. Media hora de lectura resuelve la mayoría de las dudas de los seis criterios.
Concederle lo mínimo
Y una vez adoptado, lo de la fase V:
- Concede solo los permisos que uses, no el conjunto que su documentación sugiere.
- Ponle ámbito si lo admite.
- Y anota por qué lo añadiste, con el registro del nivel 26.5.
Y revisa periódicamente si sigues usándolo: un plugin que se añadió para una función que se quitó sigue ampliando la superficie.