Bun publicó la versión 1.4.2 para corregir una falla de su empaquetador que rompía aplicaciones construidas con Elysia y actualizar el motor WebKit; pnpm lanzó dos parches seguidos para revertir una regresión que hacía fallar toda instalación sobre Vercel; GitHub advirtió que la llave PGP de sus paquetes de Linux venció este sábado 5 de setiembre; Docker publicó la versión 29.8.0 de su motor con una bandera nueva de permisos y un cierre de seguridad en sockets AF_VSOCK; y Cloudflare workerd llegó a 26 días consecutivos de lanzamientos diarios.
La versión 1.4.2, publicada el 5 de setiembre, corrige un error de shadowing de variables en el empaquetador, ajusta el evento "online" de los hilos de trabajo y actualiza el motor WebKit con 354 cambios.
El equipo de Bun publicó, el 5 de setiembre de 2026 a las 05:55 UTC, la versión 1.4.2 del entorno de ejecución de JavaScript, un parche de cinco cambios según el registro oficial de versiones del proyecto en GitHub. El más urgente corrige un error del empaquetador (bundler) que contaba la declaración de una variable como un uso de esa misma variable dentro del ámbito donde se imprime, lo que producía el error "SyntaxError: Cannot declare a var variable" en aplicaciones construidas con el framework Elysia; otro cambio hace que el evento 'online' de los hilos de trabajo (worker_threads) se dispare antes de que corra el punto de entrada, para igualar el comportamiento de Node.js, y un tercero corrige un cierre abrupto (panic) por doble cierre de descriptor de archivo cuando un escritor de tubería POSIX fallaba al iniciar en pruebas aisladas. La misma entrega actualiza el motor WebKit a un punto de referencia que incorpora 354 cambios de la rama original, de acuerdo con la misma fuente. Los cinco cambios llegan un día después de que esta sección documentara la versión 1.4.1, que estrenó HTTP/2 nativo en Bun.serve() y escritura de respuestas directo a disco: el patrón se repite semana a semana en Bun, donde una entrega de funciones nuevas suele ir seguida, en menos de 24 horas, de un parche que corrige regresiones que esa misma entrega introdujo en el empaquetador o en la compatibilidad con Node.js. Que el error de shadowing rompiera específicamente aplicaciones con Elysia —uno de los frameworks web más usados sobre Bun— es el dato que explica la urgencia del parche: no era un caso extremo aislado, sino un error de compilación que podía bloquear el arranque de aplicaciones ya en desarrollo. La información de esta nota proviene únicamente del registro oficial de versiones de Bun en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de adopción de Bun, pero el runtime gana terreno entre equipos de desarrollo locales de zonas francas tecnológicas que buscan alternativas más rápidas a Node.js; equipos que ya actualizaron a la 1.4.1 y usan Elysia deberían aplicar hoy mismo la 1.4.2 para evitar el error de compilación corregido en esta versión.
El equipo de pnpm publicó, el 4 de setiembre de 2026, las versiones 12.3.3 y 12.3.4 de su gestor de paquetes para corregir una regresión de la versión 12.3 —publicada dos días antes— que dejó de aceptar banderas booleanas como argumentos de línea de comandos, entre ellas --unsafe-perm, según el registro oficial de versiones del proyecto en GitHub. El propio registro de cambios describe el efecto de la regresión en términos directos: la pérdida de esa bandera "failed every install on Vercel" que dependiera de ella. La versión 12.3.4 suma además soporte de --unsafe-perm al comando pnpm remove, para igualarlo con el resto de comandos, y acelera la resolución de dependencias en espacios de trabajo (workspaces) grandes. El dato que matiza la semana de pnpm es que esta misma versión 12.3 fue la que, apenas el jueves, esta sección documentó como el cierre de brecha que extendía las políticas de confianza contra ataques a la cadena de suministro —pensadas para frenar campañas como la del gusano Shai-Hulud— a los comandos remove y update. La entrega pensada para hacer más segura la instalación de paquetes terminó, en la práctica, rompiendo la instalación por completo para cualquier flujo de trabajo que dependiera de --unsafe-perm, incluidos los despliegues automáticos de Vercel: un recordatorio de que un endurecimiento de seguridad no llega necesariamente sin costo, y de que ese costo se descubre más rápido y más ruidosamente en una tubería de integración continua que falla en cada corrida que en un uso manual ocasional. La información de esta nota proviene únicamente del registro oficial de versiones de pnpm en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de uso de pnpm, pero el gestor gana terreno entre equipos de desarrollo locales de zonas francas tecnológicas que despliegan sobre plataformas como Vercel; equipos que actualizaron a la versión 12.3, 12.3.1 o 12.3.2 y usan --unsafe-perm en sus flujos de despliegue deberían confirmar hoy que ya corren la 12.3.4.
cat /feed/herramientasdevgithubcli.md
La llave PGP que firma los paquetes APT y RPM de GitHub CLI para Linux venció el 5 de setiembre; desde esa fecha, todo se firma solo con la llave de reemplazo.
> GitHub publicó, el 3 de setiembre de 2026, un aviso advirtiendo que la llave PGP que firma los repositorios APT y RPM de GitHub CLI (gh) para Linux —con huella digital 2C6106201985B60E6C7AC87323F3D4EA75716059— vencía el sábado 5 de setiembre de 2026, según el registro oficial de cambios de GitHub. Desde esa fecha, los metadatos de esos repositorios y todo paquete RPM nuevo se firman únicamente con la llave de reemplazo, con huella 7F38BBB59D064DBCB3D84D725612B36462313325, que GitHub había publicado en abril de 2026 dentro de un llavero (keyring) que incluía ambas llaves durante la transición, de acuerdo con la misma fuente y con el seguimiento del proceso en el issue #13118 del repositorio cli/cli.
> El cambio solo afecta a quienes instalaron gh desde los repositorios oficiales de APT o RPM antes del 8 de abril de 2026 y no actualizaron su configuración desde entonces; quienes usan Windows, macOS, Homebrew, los binarios publicados en GitHub Releases o compilan gh desde el código fuente quedan fuera del aviso, según la misma fuente. El riesgo concreto para quien no actualizó la llave es que el gestor de paquetes del sistema deje de validar la firma de las próximas actualizaciones de gh, lo que en la práctica bloquea instalar o actualizar el paquete hasta corregir la configuración del repositorio.
> La información de esta nota proviene únicamente del registro oficial de cambios de GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de instalaciones de GitHub CLI vía APT o RPM, pero equipos de desarrollo locales en bancos y zonas francas tecnológicas que administran servidores Linux con gh instalado desde esos repositorios deberían confirmar hoy mismo que su configuración incluye la llave nueva, siguiendo las instrucciones que GitHub publicó en abril.
Docker publicó, el 3 de setiembre de 2026, la versión 29.8.0 de su motor de contenedores (Moby), que agrega la bandera --umask para los comandos docker create y docker run —permite fijar la máscara de permisos del proceso dentro del contenedor—, amplía el controlador de registro de CloudWatch con nombres de servicio y atributos personalizados, suma soporte para personalizar perfiles de AppArmor y bloquea el acceso a la llamada socketcall de 32 bits sobre sockets AF_VSOCK, según el registro oficial de versiones del proyecto en GitHub. La misma entrega corrige un caso en que docker network inspect no encontraba una red de Swarm saludable cuando otra red de Swarm no podía asignarse, un problema de resolución de nombres de servicio en Swarm y el ordenamiento alfabético —en lugar de numérico— de puertos, y actualiza sus dependencias internas a BuildKit 0.33.0, containerd 2.3.4, Go 1.26.8 y runc 1.5.1. El bloqueo del acceso de 32 bits a socketcall sobre AF_VSOCK cierra una vía que, en configuraciones de virtualización que exponen sockets vsock al contenedor, podía usarse para invocar esa llamada de sistema por una ruta de compatibilidad de 32 bits pensada para binarios antiguos; Docker no documenta explotación conocida de esa vía, pero la trata como corrección de seguridad y no solo como saneamiento de código, según el mismo registro de cambios. La actualización llega junto con Docker Compose 5.5.1, publicado el mismo día, que agrega captura de la salida de los hooks de ciclo de vida y mejora el reporte de errores de las trazas de OpenTelemetry.
Cloudflare publicó, el 6 de setiembre de 2026 a la 01:12 UTC, la versión 1.20260906.1 de workerd, el motor de ejecución de Cloudflare Workers, con un único cambio de fondo: adelantar en un día la fecha máxima de compatibilidad que acepta el runtime, del 12 al 13 de setiembre de 2026, según el registro oficial de lanzamientos del proyecto en GitHub. Es la vigésimo sexta entrega consecutiva de la racha diaria de lanzamientos de Cloudflare workerd, sostenida sin interrupciones desde el 12 de agosto, de acuerdo con el mismo registro. A diferencia de las versiones de los tres días previos —que sumaron soporte de thread sanitizer en macOS, preservaron el estado de una promesa reemplazada por otra dentro del runtime y revirtieron dos cambios de entregas anteriores—, la de hoy no modifica ningún comportamiento del runtime: es, en la práctica, el mismo binario con la ventana de fechas de compatibilidad corrida un día hacia adelante, el tipo de entrega mínima que sostiene una racha diaria sin aportar necesariamente una funcionalidad nueva cada vez. La información de esta nota proviene únicamente del registro oficial de lanzamientos de Cloudflare Workerd en GitHub, sin cobertura cruzada de otro medio al cierre de esta edición. Costa Rica no publica cifras propias de tráfico servido por Cloudflare Workers, pero equipos locales de zonas francas tecnológicas que corren cargas sobre la plataforma no necesitan ninguna acción con esta versión: el cambio de hoy es un ajuste de fecha de compatibilidad sin efecto en aplicaciones ya desplegadas.
Entre el parche que Bun publicó para su empaquetador y la racha de 26 días de Cloudflare workerd, esta edición documenta cinco desarrollos recientes del ecosistema de programación.
Esta edición documentó cinco desarrollos del 3 al 6 de setiembre de 2026: la versión 1.4.2 de Bun, que corrigió una falla de su empaquetador que rompía aplicaciones con Elysia y actualizó el motor WebKit; las versiones 12.3.3 y 12.3.4 de pnpm, que revirtieron una regresión de la 12.3 que hacía fallar toda instalación sobre Vercel que dependiera de la bandera --unsafe-perm; el vencimiento, este sábado, de la llave PGP que firma los paquetes de Linux de GitHub CLI; la versión 29.8.0 de Docker Engine, con una bandera nueva de permisos y el cierre de una vía de 32 bits hacia AF_VSOCK; y la versión 1.20260906.1 de Cloudflare workerd, la vigésimo sexta entrega consecutiva de su racha diaria. El hilo más claro de esta edición conecta dos historias de pnpm: la misma versión 12.3 que esta sección celebró el jueves por extender sus políticas de confianza contra la cadena de ataques de Shai-Hulud resultó ser, también, la que rompió las instalaciones automáticas sobre Vercel al perder una bandera de línea de comandos —un endurecimiento de seguridad que llegó con un costo operativo real, descubierto y corregido en cuestión de días. Cloudflare workerd, mientras tanto, sigue siendo el hilo más constante que esta sección ha seguido en setiembre: 26 días de lanzamientos diarios sin interrupción, aunque el de hoy no cambia una sola línea de comportamiento del runtime. Para equipos de desarrollo en Costa Rica, la acción concreta de esta edición combina dos frentes: quien administra servidores Linux con GitHub CLI instalado desde APT o RPM debe confirmar hoy que su configuración ya usa la llave de reemplazo, y quien despliega sobre Vercel con pnpm y la bandera --unsafe-perm debe confirmar que ya corre la versión 12.3.4. El resto de la lista —Bun, Docker y Cloudflare workerd— queda en fase de observación de rutina.