PRNext 0.1.15: bases de tiempo de ejecución más sólidas

#TLS y validación de certificado

El lanzamiento actualizó Rustls, Rustls-webpki y webpki-root-certs, incluida una solución para un certificado intermedio de emSign que no es de confianza.

Este trabajo se refiere a la cadena de dependencia del tiempo de ejecución nativo. Las dependencias de sus propias aplicaciones y los servicios externos aún tienen sus propios requisitos de actualización.

La validación del certificado pertenece a la ruta de conexión, por lo que una dependencia nativa parcheada es importante incluso cuando el origen de la aplicación no cambia. Pruebe los servicios HTTPS externos en los que depende su aplicación después de la reconstrucción. Una solicitud exitosa a un servicio no establece que cada cadena de certificados o cliente específico de la aplicación esté cubierto.

#Representación de imágenes y gráficos abiertos

El bloqueo de dependencia se movió a Sharp 0.35.5 y source-map-js 1.2.2.. El renderizador Open Graph enviado fue reconstruido, con un respaldo resvg cuando un backend nativo opcional de Sharp tiene un librsvg faltante o anterior a 2.63.2.

Verificar solo una anulación del espacio de trabajo no es suficiente para el código que ya está incrustado en un renderizador distribuido. La salida empaquetada también debe incluir la dependencia corregida.

La alternativa se refiere a cómo el renderizador empaquetado maneja su backend de imagen nativa. Verifique tanto una imagen optimizada ordinaria como una imagen Open Graph generada en la aplicación creada. Esas rutas pueden ejecutar código diferente, por lo que una miniatura correcta por sí sola no es una verificación completa de la generación de imágenes sociales.

#Una línea base Node.js parcheada

Las líneas de versión admitidas comienzan en Node.js 22.23.4, 24.22.1 y 26.12.1.. El ejecutable del nodo local y las imágenes de contenedor implementadas necesitan su propia actualización; instalar un paquete npm no los reemplaza.

Trate el tiempo de ejecución del nodo y el artefacto de la aplicación como dos partes de la implementación. Registre qué ejecutable o imagen de contenedor inicia la aplicación, reconstruya con las versiones de paquete deseadas y verifique el servicio en ejecución después del reinicio. Esto evita mantener un archivo de bloqueo parcheado junto a un proceso que todavía utiliza un tiempo de ejecución más antiguo.

#A dónde ir desde aquí

Utilice las instrucciones 0.1.16 para el paquete documentadas en la guía de instalación, reconstruya su aplicación y reinicie la salida implementada. Los cambios de desarrollo y caché en 0.1.17 se tratan en sus propios artículos versionados.

Mantenga un registro del artefacto y el tiempo de ejecución que pasó esas comprobaciones. Si necesita revertir el código de la aplicación, ese registro ayuda a distinguir una reversión funcional de la reintroducción de una dependencia obsoleta. Valide el resultado de reemplazo en lugar de asumir que una imagen anterior tiene las mismas propiedades de seguridad.