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
Les versions majeures de Node.js passent au statut de version _Current_ pendant six mois, ce qui donne aux auteurs de bibliothèques le temps de les prendre en charge.
11
+
Après six mois, les versions impaires (9, 11, etc.) ne sont plus supportées, et les versions paires (10, 12, etc.) passent au statut _Active LTS_ et sont prêtes pour une utilisation générale.
12
+
Le statut de la version _LTS_ correspond à un "support à long terme", qui garantit généralement que les bogues critiques seront corrigés pendant une durée totale de 30 mois.
13
+
Les applications de production ne doivent utiliser que les versions _Active LTS_ ou _Maintenance LTS_.
Tous les détails concernant le calendrier des versions de Node.js sont disponibles [sur GitHub](https://github.com/nodejs/release#release-schedule).
20
+
21
+
## Vous cherchez la dernière version d'une branche de version ?
22
+
23
+
<PreviousReleasesTable />
24
+
25
+
## Méthodes d'installation officielles ou communautaires
26
+
27
+
Le site web de Node.js propose plusieurs méthodes d'installation non interactives, notamment des interfaces en ligne de commande (CLI), des gestionnaires de paquets de systèmes d'exploitation (par exemple, `brew`) et des gestionnaires de versions de Node.js (par exemple, `nvm`).
28
+
29
+
Pour mettre en valeur et promouvoir les contributions de la communauté, le projet Node.js a introduit une page de téléchargement révisée classant les méthodes d'installation en deux catégories : "Officielle" et "Communautaire". Les utilisateurs bénéficient ainsi d'une plus grande flexibilité et d'un plus grand choix. Pour plus de clarté, nous avons défini des critères pour chaque catégorie.
30
+
31
+
### Méthodes d'installation officielles
32
+
33
+
Les méthodes d'installation désignées comme "Officielles" doivent satisfaire aux exigences suivantes :
| Les nouvelles versions de Node.js doivent être disponibles en même temps que la version officielle. |
38
+
| Les responsables de projet doivent avoir une relation étroite avec le projet Node.js, y compris des canaux de communication directs. |
39
+
| La méthode d'installation doit télécharger les binaires officiels fournis par le projet Node.js. |
40
+
| La méthode d'installation ne doit pas construire à partir des sources lorsque des binaires préconstruits sont disponibles, et ne doit pas non plus modifier les binaires officiels. |
41
+
42
+
### Méthodes d'installation de la communauté
43
+
44
+
Les méthodes d'installation communautaires incluses dans la page de téléchargement en libre-service (/download) doivent également respecter un ensemble minimum de critères :
45
+
46
+
-_Prise en charge des versions :_\* Doit prendre en charge toutes les versions de Node.js actuellement prises en charge et qui ne sont pas en fin de vie.
47
+
-**Compatibilité avec les systèmes d'exploitation :** Doit fonctionner sur au moins un système d'exploitation officiellement pris en charge.
48
+
-**Prise en charge étendue du système d'exploitation :** Ne peut être limité à un sous-ensemble de distributions ou de versions du système d'exploitation.
49
+
- Par exemple, une méthode d'installation revendiquant la compatibilité avec "Windows" doit fonctionner sur "Windows 10", "Windows 11", et toutes leurs éditions (y compris les versions serveur).
50
+
- De même, une méthode d'installation revendiquant la compatibilité avec "Linux" doit pouvoir être installée sur toutes les distributions Linux majeures, et pas seulement sur un sous-ensemble spécifique. Elle ne peut pas s'appuyer sur des gestionnaires de paquets spécifiques à une distribution comme `apt` ou `dnf`.
51
+
-**Libre et Open Source:** Doit être libre d'utilisation et open source, ne doit pas être vendu comme un produit commercial, et ne doit pas être un service payant.
Copy file name to clipboardExpand all lines: apps/site/pages/fr/about/security-reporting.mdx
+19-24Lines changed: 19 additions & 24 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -11,9 +11,10 @@ Pour plus de détails sur les politiques de sécurité active, consultez [cette
11
11
12
12
Signalez les bogues de sécurité dans Node.js via [HackerOne](https://hackerone.com/nodejs).
13
13
14
-
Vous recevrez un accusé de réception de votre rapport dans les 5 jours, et vous recevrez une réponse plus détaillée dans les 10 jours, indiquant les prochaines étapes.
15
-
une réponse plus détaillée à votre rapport dans les 10 jours, indiquant les prochaines étapes du traitement de votre demande.
16
-
traitement de votre demande.
14
+
Normalement, votre signalement de bug sera pris en compte dans les 5 jours, et vous recevrez
15
+
une réponse plus détaillée à votre soumission dans les 10 jours, indiquant les
16
+
prochaines étapes du traitement de votre signalement. Ces délais peuvent être prolongés lorsque
17
+
nos bénévoles chargés du triage sont en vacances, en particulier en fin d'année.
17
18
18
19
Après la réponse initiale à votre rapport, l'équipe de sécurité s'efforcera de vous tenir informé des progrès réalisés en vue d'un correctif et d'une annonce complète.
19
20
vous tenir informé des progrès réalisés en vue d'une correction et d'une annonce complète,
@@ -34,30 +35,25 @@ Les bogues de sécurité dans les modules tiers doivent être signalés à leurs
34
35
35
36
Voici la politique de divulgation de la sécurité pour Node.js
36
37
37
-
- Le rapport de sécurité est reçu et un gestionnaire principal lui est attribué. Cette personne
38
-
Cette personne coordonnera le processus de correction et de libération. Le problème est confirmé
39
-
et une liste de toutes les versions affectées est établie. Le code est audité pour trouver
40
-
tout problème similaire potentiel. Des correctifs sont préparés pour toutes les versions qui sont
41
-
toujours en cours de maintenance. Ces correctifs ne sont pas déposés dans le
42
-
mais sont plutôt conservés localement dans l'attente de l'annonce.
38
+
- Le rapport de sécurité est reçu et attribué à un responsable principal. Cette
39
+
personne coordonnera le processus de correction et de publication. Le problème est validé
40
+
pour toutes les versions Node.js prises en charge. Une fois confirmé, une liste de toutes les versions concernées
41
+
est établie. Le code est audité afin de détecter tout problème similaire potentiel.
42
+
Des correctifs sont préparés pour toutes les versions prises en charge.
43
+
Ces correctifs ne sont pas enregistrés dans le référentiel public, mais conservés localement
44
+
en attendant l'annonce.
43
45
44
46
- Une date d'embargo est proposée pour cette vulnérabilité et un CVE (Common Vulnerabilities and Exposures (CVE®)) est demandé pour cette vulnérabilité.
45
47
Vulnérabilités et expositions communes (CVE®) est demandé pour la vulnérabilité.
46
48
47
-
- À la date d'embargo, la liste de diffusion sur la sécurité de Node.js reçoit une copie de l'annonce.
48
-
annonce. Les changements sont poussés vers le dépôt public et de nouvelles versions
49
-
sont déployées sur nodejs.org. Dans les 6 heures suivant la notification de la liste de diffusion
50
-
une copie de l'avis sera publiée sur le blog de Node.js.
49
+
- À la date d'embargo, une copie de l'annonce est envoyée à la liste de diffusion de sécurité Node.js.
50
+
Les modifications sont poussées vers le référentiel public et de nouvelles
51
+
versions sont déployées sur nodejs.org. Dans les 6 heures suivant la notification de la liste de diffusion, une copie de l'avis sera publiée sur le blog Node.js.
51
52
52
-
- En règle générale, la date d'embargo est fixée à 72 heures à compter de l'émission du CVE.
53
-
est publié. Toutefois, cela peut varier en fonction de la gravité du bogue ou de la
54
-
de la difficulté à appliquer un correctif.
53
+
- En règle générale, la date d'embargo est fixée à 72 heures à compter de la publication du CVE.
54
+
Toutefois, cela peut varier en fonction de la gravité du bug ou de la difficulté à appliquer un correctif.
55
55
56
-
- Ce processus peut prendre un certain temps, en particulier lorsqu'une coordination est nécessaire avec les responsables d'autres projets.
57
-
avec les responsables d'autres projets. Tous les efforts seront faits pour traiter le
58
-
bogue le plus rapidement possible ; cependant, il est important que nous suivions la
59
-
processus de publication ci-dessus pour s'assurer que la divulgation est traitée de manière
60
-
de manière cohérente.
56
+
- Ce processus peut prendre un certain temps, en particulier lorsque nous devons nous coordonner avec les responsables d'autres projets. Nous nous efforcerons de traiter le bogue aussi rapidement que possible ; toutefois, nous devons suivre le processus de publication ci-dessus afin de garantir une gestion cohérente de la divulgation.
61
57
62
58
## Recevoir les alertes de sécurité
63
59
@@ -68,9 +64,8 @@ Les notifications de sécurité seront diffusées par les méthodes suivantes.
68
64
69
65
## Commentaires sur cette politique
70
66
71
-
Si vous avez des suggestions sur la façon dont ce processus pourrait être amélioré, veuillez soumettre une
72
-
[pull request](https://github.com/nodejs/nodejs.org) ou
73
-
[file an issue](https://github.com/nodejs/security-wg/issues/new) pour en discuter.
67
+
Si vous avez des suggestions pour améliorer ce processus, veuillez consulter
68
+
le référentiel [nodejs/security-wg](https://github.com/nodejs/security-wg).
## Pourquoi et comment les versions de Node.js arrivent en fin de vie
9
+
10
+
Les versions majeures de Node.js sont publiées, corrigées et déclarées en fin de vie selon un calendrier prévisible. Comme il n'est pas possible de maintenir toutes les versions à perpétuité, après une période de maintenance planifiée, une version majeure de Node.js ne sera plus prise en charge par le projet.
<span>Obtenez une assistance en matière de sécurité pour les versions en fin de vie (EOL)</span>
21
+
</Button>
22
+
</div>
23
+
24
+
[Consultez le calendrier des versions de Node.js](/about/releases/).
25
+
26
+
## Que se passe-t-il lorsqu'une ligne de versions arrive en fin de vie ?
27
+
28
+
Lorsqu'une version arrive en fin de vie, cela signifie qu'elle ne recevra plus de mises à jour, y compris les correctifs de sécurité. Cela peut rendre les applications fonctionnant sur ces versions vulnérables à des problèmes de sécurité et à des bogues qui ne seront jamais corrigés.
29
+
30
+
-**Plus aucune correction de vulnérabilité** : lorsque de nouvelles versions de sécurité révèlent des problèmes et des correctifs dans les versions majeures plus récentes, même si la même vulnérabilité affecte les versions en fin de vie (EOL), aucune nouvelle version ne sera publiée pour celles-ci. Les utilisateurs qui continuent à utiliser les versions EOL et les chemins d'accès au code affectés seront immédiatement exposés aux attaques exploitant ces vulnérabilités divulguées.
31
+
-**Rupture de la chaîne d'outils** : les versions en fin de vie (EOL) peuvent ne plus être liées dynamiquement aux versions plus récentes des bibliothèques partagées dont elles dépendent, ce qui bloque ou interrompt les mises à jour du système.
32
+
-**Dérive de l'écosystème** : de nombreux paquets populaires destinés aux utilisateurs cessent progressivement de prendre en charge les versions EOL de Node.js. Lorsqu'une application continue d'utiliser des paquets obsolètes, elle peut souffrir d'un nombre encore plus important de vulnérabilités et de bogues non corrigés, s'éloignant ainsi davantage de la norme de l'écosystème.
33
+
-**Signaux d'alerte en matière de conformité** : de nombreux audits sectoriels interdisent les environnements d'exécution non maintenus.
34
+
35
+
## Versions en fin de vie
36
+
37
+
<EOLReleaseTable />
38
+
39
+
## Support Commercial
40
+
41
+
Malgré les inconvénients évidents liés à l'utilisation des versions en fin de vie, dans la pratique, les organisations sont confrontées à des contraintes qui les empêchent de procéder à des mises à niveau immédiates, telles que les bases de code héritées, les exigences de conformité ou les chaînes de dépendances complexes. Pour les utilisateurs qui ne peuvent pas procéder à une mise à niveau immédiate mais qui ont besoin d'une assistance continue en matière de sécurité pour les versions en fin de vie de Node.js, une assistance commerciale est disponible dans le cadre du partenariat [OpenJS Ecosystem Sustainability Program](https://openjsf.org/blog/ecosystem-sustainability-program).
42
+
43
+
Node.js s'est associé à HeroDevs pour fournir une assistance permanente (NES) pour les versions de Node.js qui ont dépassé leur phase de maintenance officielle. Cela comprend des correctifs de sécurité, une aide à la conformité et une assistance technique pour vous aider à combler le fossé pendant que vous planifiez votre stratégie de mise à niveau. Pour plus d'informations, consultez la [**page HeroDevs Node.js NES**](https://nodejs.org/esp/herodevs).
44
+
45
+
L'utilisation des versions EOL(fin de vie) via NES doit être considérée comme une solution temporaire. L'objectif doit toujours être de passer à des versions activement prises en charge.
![github-merge-queue[bot]](https://avatars.githubusercontent.com/u/9919?v=4&size=40){kind=avatar}
0 commit comments