You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
description: Entender la fase fin de vida útil de Node.js, su significado para seguridad, herramientas, y cumplimiento, junto con detalles de las versiones EOL y opciones para soporte comercial.
5
+
---
6
+
7
+
# Fin de Vida Útil (EOL)
8
+
9
+
## Cómo y por qué los lanzamientos de Node.js tienen un fin de vida útil
10
+
11
+
Existe un horario regular para lanzar, remendar, y pasar al fin de vida útil las versiones principales de Node.js. No es posible mantener cada versión principal para siempre, entonces una vez pasado un período predeterminado, el proyecto Node.js dejará de mantener una versión principal.
<span>Obtener soporte de seguridad para versiones EOL</span>
22
+
</Button>
23
+
</div>
24
+
25
+
[Ve el calendario de lanzamientos de Node.js](/about/releases/).
26
+
27
+
## Que sucede cuando un lanzamiento pasa su fin de vida útil
28
+
29
+
Cuando una versión pasa su fin de vida útil (EOL), deja de recibir actualizaciones como remiendas de seguridad. Como resultado, las aplicaciones que usan estas versiones pueden volver vulnerables a defectos de seguridad y otros errores que nunca serán arreglados.
30
+
31
+
-**No más correcciones de vulnerabilidades**: Cuando se publiquen nuevas versiones de seguridad que revelen problemas y parches en líneas principales más recientes, no habrá nuevas versiones para líneas de lanzamiento EOL, incluso si la misma vulnerabilidad afecta a líneas de lanzamiento EOL. Los usuarios que aún se aferran a líneas de lanzamiento EOL y utilizan rutas de código afectadas serán inmediatamente vulnerables a ataques que exploten estas vulnerabilidades divulgadas.
32
+
-**Errores en la cadena de herramientas**: Los lanzamientos EOL pueden dejar de vincular con versiones nuevas de dependencias externas, el cual podría impedir actualizaciones futuras.
33
+
-**Cambios en el ecosistema**: Varios paquetes populares dejan de funcionar con versiones EOL de Node.js. Cuando una aplicación depende de paquetes anticuados, puede sufrir de más vulnerabilidades y fallos, volviéndose más difícil de reconciliar con el ecosistema actual.
34
+
-**Incumplimiento**: A menudo, las auditorías prohíben sistemas de runtime no mantenidos.
35
+
36
+
## Versiones EOL
37
+
38
+
<EOLReleaseTable />
39
+
40
+
## Soporte Comercial
41
+
42
+
A pesar de las desventajas obvias de usar versiones EOL, en la práctica, las organizaciones enfrentan restricciones que impiden actualizaciones inmediatas, como bases de código heredadas, requisitos de cumplimiento o cadenas de dependencias complejas. A través del [Programa de Sostenibilidad del Ecosistema de la Fundación OpenJS](https://openjsf.org/blog/ecosystem-sustainability-program), Node.js cuenta con el apoyo de HeroDevs y NodeSource para proporcionar servicios comerciales para correcciones de seguridad.
43
+
44
+
HeroDevs ofrece un [Soporte Interminable (NES)](https://nodejs.org/esp/herodevs) para versiones de Node.js que ya no tienen soporte oficial. Esto incluye parches de seguridad, ayuda con cumplimiento y soporte técnico para darte tiempo mientras planificas tu actualización.
45
+
46
+
Usar versiones EOL con soporte comercial debería verse como una solución temporal, el objetivo siempre debería ser actualizar a versiones con soporte activo.
Copy file name to clipboardExpand all lines: apps/site/pages/es/about/get-involved/index.md
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -31,4 +31,5 @@ Ten en cuenta que el proyecto Node.js no respalda oficialmente estas áreas. Por
31
31
32
32
-[Node Slackers](https://www.nodeslackers.com/) es una comunidad de slack enfocada en Node.js.
33
33
-[OpenJSF Slack](https://slack-invite.openjsf.org/) es un espacio de trabajo en Slack para la Fundación OpenJS. Hay varios canales relacionados con Node.js. _(los canales con el prefijo `#nodejs-` están relacionados con el proyecto)_
34
+
-[r/node](https://www.reddit.com/r/node/) es un subreddit que se enfoca en Node.js.
34
35
-`irc.libera.chat` en el canal `#node.js` con un [cliente IRC](https://es.wikipedia.org/wiki/Comparaci%C3%B3n_de_clientes_de_Internet_Relay_Chat) o conéctate en tu navegador web al canal usando [un cliente web](https://kiwiirc.com/nextclient/).
Las versiones principales de Node.js entran en estado de lanzamiento _Actual_ durante seis meses, lo que les da a los autores de bibliotecas tiempo para agregarles manutención.
11
+
Después de seis meses, las versiones impares (9, 11, etc.) dejan de ser compatibles y las versiones pares (10, 12, etc.) pasan al estado _LTS Activo_ y están listas para uso general.
12
+
El estado de la versión _LTS_ es "soporte a largo plazo", que normalmente garantiza que los errores críticos se corregirán durante un total de 30 meses.
13
+
Las aplicaciones de producción solo deben usar versiones _LTS Activo_ o _LTS en Mantenimiento_.
Los detalles del calendario de lanzamiento de Node.js están disponibles [en GitHub](https://github.com/nodejs/release#release-schedule).
20
+
21
+
## ¿Buscando las últimas versiones de una rama específica?
22
+
23
+
<PreviousReleasesTable />
24
+
25
+
## Métodos de Instalación Oficial vs. Comunidad
26
+
27
+
El sito web de Node.js ofrece varios métodos de instalación que facilitan una instalación de Node.js sin interacción, como por una interfaz de línea de comandos (CLI), gestores de paquetes del sistema operativo (OS) (e.g. `brew`), o gestores de versiones de Node.js (e.g. `nvm`).
28
+
29
+
En un intento de anunciar y popularizar esfuerzos comunitarios, el proyecto Node.js ha introducido una página de Descargas actualizada que distingue entre métodos de instalación Oficial y de la Comunidad. Esta presentación provee más flexibilidad y opciones para usuarios. Para evitar confusión, hemos definido requisitos para cada designación.
30
+
31
+
### Métodos de Instalación Oficiales
32
+
33
+
Para considerarse "Oficial", métodos de instalación deben cumplir con los siguientes requisitos:
| Lanzamientos nuevos de Node.js deben estar disponible al mismo tiempo que el lanzamiento oficial. |
38
+
| Los mantenedores del proyecto tienen una estrecha relación con Node.js, la cual incluye comunicación directa. |
39
+
| El método de instalación debe descargar los binarios oficiales empaquetados por el proyecto Node.js. |
40
+
| El método de instalación no compila desde el código fuente cuando binarios están disponibles, ni modifica los binarios oficiales proveídos por Node.js. |
41
+
42
+
### Métodos de Instalación de Comunidad
43
+
44
+
Para ser incluida en la página de descargas (/download), los métodos de instalación de comunidad deben cumplir con unos requisitos mínimos:
45
+
46
+
-**Apoyo de versiones:** Debe proveer instalaciones de cada versión de Node.js apoyado oficialmente que no ha pasado el fin de su vida útil (EOL).
47
+
-**Compatibilidad con Sistemas Operativos**: Debe operar en uno o más sistemas operativos oficialmente compatible.
48
+
-**Apoyo amplio de Sistemas Operativos:** No se puede limitar a una fracción de distribuciones o versiones del sistema operativo.
49
+
- Por ejemplo, si un método de instalación declara compatibilidad con "Windows", debe funcionar en cada edición de "Windows 10" y "Windows 11" (incluso versiones para servidores).
50
+
- De igual manera, un método de instalación que declara compatibilidad con "Linux" debe poder instalarse en cada una de las distribuciones principales de Linux, y no solo una selección reducida. No puede depender de un gestor de paquetes específico a una distribución en particular como `apt` o `dnf`.
51
+
-**Gratis y de Código Abierto:** Debe ser de código abierto que puede usarse gratuitamente y no como producto comercial vendido ni un servicio pagado.
Copy file name to clipboardExpand all lines: apps/site/pages/es/about/security-reporting.mdx
+6-15Lines changed: 6 additions & 15 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,7 +11,7 @@ Para más detalles de las Políticas de Seguridad activas, revise esta [página]
11
11
12
12
Reporta errores de seguridad de Node.js atreves de [HackerOne](https://hackerone.com/nodejs).
13
13
14
-
Su informe será reconocido dentro de 5 días, y recibirás una respuesta más detallada a tu informe dentro de 10 días donde indicara los próximos pasos para manejar su entrega.
14
+
Normalmente, la confirmación de recepción de los informes suele tardar hasta 5 días. Dentro de 10 días, se puede esperar una respuesta más detallada que indica los pasos siguientes. Se pueden alargar estos plazos cuando nuestros voluntarios de clasificación están de vacaciones, como el fin del año.
15
15
16
16
Después de la respuesta inicial a tu informe, el equipo de seguridad se esforzará por mantenerte informado sobre el progreso hacia una solución y el anuncio completo, y puede solicitar información adicional u orientación sobre el problema reportado.
17
17
@@ -28,15 +28,15 @@ mantenedores.
28
28
29
29
Aquí está la política de divulgación de seguridad para Node.js:
30
30
31
-
- El informe de seguridad es recibido y se asigna a un responsable principal. Esta persona coordinará el proceso de corrección y lanzamiento. El problema es confirmado y se determina una lista de todas las versiones afectadas. Se audita el código para encontrar posibles problemas similares. Se preparan correcciones para todas las versiones que aún están en mantenimiento. Estas correcciones no se comprometen al repositorio público, sino que se mantienen localmente a la espera del anuncio.
31
+
- El informe de seguridad es recibido y se asigna a un responsable principal. Esta persona coordinará el proceso de corrección y lanzamiento. El problema es convalidada en cada versión de Node.js soportada. Una vez confirmado se determina una lista de todas las versiones afectadas. Se audita el código para encontrar posibles problemas similares. Se preparan correcciones para todas las versiones soportadas. Estas correcciones no se comprometen al repositorio público, sino que se mantienen localmente a la espera del anuncio.
32
32
33
33
- Se elige una fecha de embargo sugerida para esta vulnerabilidad y un CVE (Vulnerabilidades y Exposiciones Comunes (CVE®)) será solicitado para la vulnerabilidad.
34
34
35
35
- En la fecha de embargo, se envía una copia del anuncio a la lista de correo de seguridad de Node.js. Los cambios se suben al repositorio público y se despliegan nuevas versiones en nodejs.org. Dentro de las 6 horas posteriores a que se notifique a la lista de correo, se publicará una copia del aviso en el blog de Node.js.
36
36
37
37
- Típicamente la fecha de embargo será fijada 72 horas desde la creación del CVE. Sin embargo, esto puede variar dependiendo de la severidad del error o la dificultad en aplicar la solución.
38
38
39
-
- Este proceso puede tomar algún tiempo, especialmente cuando se requiere coordinación con los mantenedores de otros proyectos. Cada esfuerzo posible se hará para encargarse del error en la forma más oportuna posible, sin embargo, es importante que sigamos el proceso descrito arriba, para asegurarse que la divulgación sea manejada de una manera consistente.
39
+
- Este proceso puede durar algún tiempo, en particular cuando requiere coordinación con mantenedores de otros proyectos. Nos esforzamos por resolver el problema con prisa; sin embargo, debemos seguir este proceso de lanzamiento para asegurar que las divulgaciones se manejan uniformemente.
40
40
41
41
## Recibiendo actualizaciones de seguridad
42
42
@@ -47,21 +47,12 @@ Las notificaciones de seguridad se distribuirán mediante los siguientes método
47
47
48
48
## Comentarios sobre esta política
49
49
50
-
Si tienes sugerencias sobre cómo podría mejorarse este proceso, por favor, envía una
51
-
[pull request](https://github.com/nodejs/nodejs.org) o
52
-
[rellena un issue](https://github.com/nodejs/security-wg/issues/new) para discutirlo.
50
+
Si quieres recomendar ideas para mejor este proceso, por favor visita el repositorio [nodejs/security-wg](https://github.com/nodejs/security-wg).
La [Insignia de Buenas Prácticas](https://github.com/coreinfrastructure/best-practices-badge) de la Fundación de Seguridad del Software Abierto (OpenSSF) es una manera en que los proyectos de Software Libre y de Código Abierto (FLOSS) pueden mostrar que siguen las mejores prácticas. Los proyectos pueden auto-certificarse voluntariamente sobre cómo siguen cada buena práctica. Los consumidores de la insignia pueden evaluar rápidamente qué proyectos FLOSS siguen las mejores prácticas y, como resultado, tienen más probabilidades de producir software seguro de alta calidad.
Le [badge des meilleures pratiques](https://github.com/coreinfrastructure/best-practices-badge) de l'Open Source Security Foundation (OpenSSF) est un moyen pour les projets de logiciels libres et open source (FLOSS) de montrer qu'ils suivent les meilleures pratiques. Les projets peuvent volontairement auto-certifier la manière dont ils suivent chaque meilleure pratique. Les utilisateurs du badge peuvent rapidement déterminer quels sont les projets FLOSS qui suivent les meilleures pratiques et qui sont donc plus susceptibles de produire des logiciels sécurisés de meilleure qualité.
0 commit comments