Próximos cambios disruptivos para npm v12

Propiedad, Microsoft y confianza

• Muchos comentaristas se sorprendieron o se molestaron de que npm pertenezca a GitHub/Microsoft; otros señalaron que eso es cierto desde 2020 y que npm ya “apestaba” antes.
• Debatieron si Microsoft realmente ha cambiado o si repite patrones de “abrace, extienda, extinga”; algunos ven GitHub/VS Code como pragmáticos, otros como bloqueo de proveedor y “open washing”.
• Se citan los despidos en torno a la adquisición de npm y, más tarde, el enfoque de GitHub en IA como prueba de que las prioridades corporativas pesan más que la salud del ecosistema.

Cambios principales de npm v12 (allowScripts, postinstall)

• El cambio principal: los scripts de instalación (por ejemplo, postinstall) están deshabilitados por defecto y deben permitirse explícitamente (allowScripts en config/package.json).
• Esto alinea npm más con pnpm y añade listas blancas por paquete, incluidas listas permitidas fijadas a versiones concretas.
• Los autores de módulos nativos y quienes distribuyen binarios mediante npm preguntaron cómo se verán afectados sus flujos de trabajo; las respuestas indican que todos los scripts de instalación están desactivados por defecto, pero los patrones existentes (os/cpu/optionalDependencies) siguen siendo viables.

Impacto en seguridad y riesgos restantes

• Muchos consideran esto una gran mejora de seguridad: elimina un vector común de la cadena de suministro, especialmente para paquetes solo de frontend donde el código nunca se ejecuta en el servidor.
• Los escépticos argumentan que el malware puede simplemente pasar de los scripts de instalación al código en tiempo de ejecución del módulo, pruebas o herramientas de compilación, de modo que la superficie de ataque se reduce, pero no desaparece.
• Algunos señalan que esta solución aborda una vulnerabilidad reportada hace unos 10 años y que solo llegó después de múltiples exploits de alto perfil, incluidos incidentes que afectaron a Microsoft mismo.

Propuestas para defensas más fuertes

• Las sugerencias incluyen:
  • Retrasos por antigüedad (por ejemplo, un retraso predeterminado de 1 día) antes de que nuevas versiones puedan instalarse.
  • 2FA obligatoria o una identidad más fuerte (documento gubernamental + aprobación con smartphone) para los publicadores.
  • Repositorios escalonados más parecidos a Debian, con control de calidad humano y soporte corporativo de pago.
  • Sandboxing, ejecuciones de simulación y mejor procedencia/permisos (mencionando Deno como un modelo más sólido).

Comparaciones del ecosistema (pnpm, yarn, otros)

• Varios comentaristas dicen que npm es “básicamente pnpm ahora”, pero pnpm se considera más rápido y más eficiente en espacio, con protecciones similares ya activadas.
• Se informa que Yarn tiene seguridad y rendimiento comparables, además de funciones como Plug’n’Play; algunos equipos migraron a pnpm por fricciones con el ecosistema.
• Deno y el propio sistema de permisos de Node se discuten como enfoques más principistas para el aislamiento en tiempo de ejecución, aunque se critican los valores predeterminados de Node.

Reacciones varias

• Opiniones mixtas sobre el cambio: desde “por fin” y “vaya, ya era hora” hasta “no sirve de nada” y “solo desplaza la culpa”.
• Quejas de interfaz sobre la insignia roja “RETIRED” de GitHub y una terminología confusa.
• Sentimiento general: mejor que nada, muy tarde y solo un paso más en una cadena de suministro de JS que sigue siendo frágil.