Próximos cambios incompatibles en npm v12

 (github.blog)
1 puntos por GN⁺ 4 시간 전 | 1 comentarios | Compartir por WhatsApp
  • En npm v12, los valores predeterminados relacionados con la seguridad de npm install cambiarán de ejecución e interpretación automáticas a un esquema de autorización explícita, y se pueden revisar con anticipación mediante advertencias en npm 11.16.0 o superior
  • El valor predeterminado de allowScripts cambiará a desactivado, bloqueando la ejecución de scripts preinstall, install y postinstall de dependencias que no hayan sido autorizadas explícitamente, así como el node-gyp rebuild implícito y los scripts prepare de dependencias git, file y link
  • Con npm approve-scripts --allow-scripts-pending se pueden revisar los paquetes que serán bloqueados, y luego usar npm approve-scripts y npm deny-scripts para decidir qué se permite o bloquea; la allowlist generada debe confirmarse en package.json
  • El valor predeterminado de --allow-git cambiará a none, por lo que se dejará de resolver dependencias Git directas y transitivas que no hayan sido autorizadas explícitamente con --allow-git
  • Se bloquea una ruta de ejecución de código por la que el .npmrc de dependencias Git podía sobrescribir el ejecutable de Git incluso cuando se usaba --ignore-scripts
  • El valor predeterminado de --allow-remote cambiará a none, por lo que se dejarán de resolver dependencias por URL remota, como tarballs https, que no hayan sido autorizadas explícitamente con --allow-remote
  • Los valores predeterminados de --allow-file y --allow-directory no cambian en npm v12
  • El procedimiento de preparación consiste en actualizar a npm 11.16.0 o superior, ejecutar una instalación normal para revisar las advertencias y aprobar solo los paquetes de confianza; después de la actualización, solo seguirán ejecutándose los scripts aprobados
  • Documentación relacionada: npm approve-scripts, npm deny-scripts, allow-scripts config

Lecturas relacionadas

1 comentarios

 
GN⁺ 4 시간 전
Comentarios de Hacker News

  • No sé cómo se me pasó que npm fue adquirido por GitHub, pero de repente muchas cosas empiezan a tener sentido
    Cuesta pensar en un peor hogar para una parte tan importante del ecosistema de Node

  • Los scripts de postinstall debieron eliminarse hace mucho tiempo; son como un cáncer en los paquetes de NPM
    Hay demasiados postinstall profundos, anidados y sin control ejecutándose aleatoriamente cuando traes cualquier cosa
    No sé quién pensó en algún momento que esto era una buena idea

    • No creo entender bien el fondo de la preocupación con los scripts post-install
      Normalmente igual vas a ejecutar en algún momento el código de dependencias empaquetado, y por lo general con los mismos permisos que en el proceso de instalación
      Entonces esos scripts de configuración, para bien o para mal, solo moverían el punto de entrada desde npm al lugar donde ocurra un import o require
      A menos que todo el ecosistema se mueva a un entorno sandbox tipo Deno, como mucho esto parece un pequeño obstáculo. Aunque quizás ese sea el plan
    • No, para nada; hay muchos casos de uso válidos
      El ejemplo que se me viene de inmediato es https://www.npmjs.com/package/patch-package
      Ojalá la histeria actual no lleve a decisiones inútiles de este tipo

  • Esto probablemente se ha discutido cientos de veces dentro de NPM desde que se reportó públicamente hace 10 años
    Por culpa de Shai Halud, ahora ya es demasiado grande para ignorarlo

    • Me gusta que la historia de JavaScript parece prácticamente una destilación de la mentalidad del desarrollador
      “Lo arreglamos pronto” casi siempre termina siendo “mierda, ahora sí hay que arreglarlo”
    • Bien, ahora le toca a Python

  • Me pregunto si las versiones actuales LTS de Node, si no recuerdo mal 22, 24 y 26, planean subir el npm incluido a v12 para beneficiarse de esta corrección de seguridad
    Ahora mismo todas incluyen npm v11

    • Ya ha pasado antes que Node meta una actualización mayor de npm en una versión intermedia
      En v18.19.0[1] y v20.10.0[2] subieron npm de 9 a 10
      [1]: https://nodejs.org/en/blog/release/v18.19.0#npm-updated-to-v...
      [2]: https://nodejs.org/en/blog/release/v20.10.0
    • Como es un cambio de valor por defecto, sí puede verse como un cambio en la postura de seguridad, pero la corrección de seguridad en sí ya está disponible para todos
      Como dice el artículo, solo hace falta configurar los valores correctos por defecto
      Lo mejor de este cambio es que, al cambiar el valor por defecto, vamos a ver romperse de inmediato esos paquetes molestos que asumen que estas configuraciones estarán activadas cuando un desarrollador nuevo simplemente corra install
      Por ejemplo, podría hacer que se abandone la práctica de asumir que se pueden ejecutar scripts

  • No queda claro solo leyendo el artículo, pero parece que la lista de scripts permitidos no es una configuración global sino que admite permisos por paquete
    Parece que será más fácil mantener reglas organizacionales que solo permitan scripts para paquetes específicos
    Me pregunto si existe algún linter que sirva para evitar valores inseguros por defecto en configuraciones del gestor de paquetes

    • ¿No bastaría con grep?

  • Me pregunto si todavía hay alguna razón para usar Yarn
    No sé si Yarn también implementó protecciones para frenar ataques a la cadena de suministro
    Hasta ahora solo conocía pnpm, así que está bien que npm también se esté poniendo al día

    • Claro que sí
      La rama actual de Yarn, 4.x, garantiza un comportamiento determinista hasta un grado quizá excesivo, y puedes esperar consistencia en todo el equipo
      En funciones, tiene muchos pequeños detalles que, una vez que te acostumbras, se acumulan y terminan marcando una gran diferencia
      La próxima versión mayor también seguirá empujando en esa misma dirección, con mejor rendimiento y funciones que hasta ahora no se habían podido implementar precisamente por depender de esas mejoras de rendimiento
      Por cierto, soy el maintainer principal de Yarn
    • Trabajé en un proyecto que usaba Yarn desde sus inicios hasta v3, y era lentísimo pero funcionaba
      También tiene funciones de protección de la cadena de suministro
      Al final ya no lo soportamos y migramos a pnpm; las instalaciones quedaron mucho más rápidas tanto en CI como en las máquinas locales
      La migración nos tomó como un día con ayuda de un LLM
    • Una diferencia es que tiene estrategias de instalación opcionales, como ejecutar paquetes directamente desde archivos comprimidos en vez de descomprimirlos en node_modules
      https://yarnpkg.com/features/pnp
      Se parece bastante a usar .jar en Java en vez de un árbol de directorios de archivos .class
      Aunque es un poco hacky, y el soporte en editores y herramientas es irregular
      Como reduce muchísimo la cantidad de archivos pequeños, puede ser especialmente más rápido si te toca trabajar en Windows sí o sí
      Incluso puedes meter los archivos comprimidos en el repositorio git, eliminando la dependencia de Internet y del registro de paquetes
    • No sé qué haga NPM, pero Yarn instala dependencias muchísimo más rápido que NPM
    • Los que me están downvoteando también pueden responder la pregunta
      De verdad no sé la respuesta

  • No sabía que npm era propiedad de GitHub
    Eso explica varias cosas

    • NPM Is Joining GitHub - https://news.ycombinator.com/item?id=22594549 (16 de marzo de 2020, 571 comentarios, 1829 puntos) - https://github.blog/news-insights/company-news/npm-is-joinin...
      Algunas partes resultan interesantes de leer con el paso del tiempo
      El comentario más votado decía: “Microsoft no hace todo bien, pero honestamente la adquisición de GitHub ha salido mucho mejor de lo que esperaba. En lugar de imponer políticas centradas en Microsoft a GitHub, Microsoft ha adoptado más cosas de GitHub desde la perspectiva de producto. GitHub sigue operando como si fuera una empresa separada”
    • La empresa NPM estuvo a punto de quebrar en 2020
      Había levantado capital de riesgo, pero no encontró un modelo de negocio sostenible
      GitHub la adquirió para salvar el ecosistema, y esa adquisición tampoco es que le haya dado grandes beneficios a GitHub
    • La mayoría sabe eso, pero lo que realmente explica muchas cosas es que GitHub pertenece a Microsoft
      Y Microsoft movió GitHub a Azure
    • Sabía que era de GitHub, pero esta es la primera vez que veo las notas de lanzamiento directamente en el blog de GitHub y no en el blog de npm

  • Me pregunto si la lista permitida en package.json fija también la versión del paquete, o solo el nombre del paquete

  • Qué bueno que allowScripts venga desactivado por defecto
    [mira el reloj] ¿Apenas 18 meses detrás de pnpm?

    • Maven en Java nunca tuvo algo así, y nunca sentí que hiciera falta
      ¿Qué propósito tiene esto del lado de JavaScript?