[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [RFR] wml://lts/security/2019/dla-1{730-4,861,866,867}.wml



Bonjour,

On 8/2/19 12:03 AM, JP Guillonneau wrote:
> Ces annonces de sécurité ont été publiées.
> Les fichiers sont aussi disponibles ici :
> https://salsa.debian.org/webmaster-team/webwml/raw/master/english/lts/security/2019/dla-xxxx.wml
> https://salsa.debian.org/webmaster-team/webwml/raw/master/french/lts/security/2019/dla-xxxx.wml
> 
> Merci d’avance pour vos relectures.

quelques suggestions après relecture complète.

Bien cordialement,
Grégoire
--- dla-1730-4.wml	2019-08-02 11:48:38.917982905 +0800
+++ gregoire.dla-1730-4.wml	2019-08-02 11:44:10.887699815 +0800
@@ -8,9 +8,9 @@
 code d’erreur LIBSSH2_ERROR_ OUT_OF_BOUNDARY.</p>
 
 <p>En remarque complémentaire, il a été découvert que l’implémentation de SFTP
-de libssh2 pour Jessie de Debian fonctionne bien seulement avec les serveurs
-SFTP OpenSSH de Wheezy de Debian, que les tests sur les nouvelles versions
-d’OpenSSH (telles que disponibles dans Jessie de Debian et au-delà) échouent
+de libssh2 de Debian Jessie fonctionne bien seulement avec les serveurs
+SFTP OpenSSH de Debian Wheezy, que les tests sur les nouvelles versions
+d’OpenSSH (telles que disponibles dans Debian Jessie et au-delà) échouent
 temporairement avec une erreur de protocole SFTP <q>Error opening remote
 file</q>. Les opérations peuvent continuer après cette erreur, cela dépend de
 l’implémentation de l’application.</p>
--- dla-1866.wml	2019-08-02 11:48:32.286006607 +0800
+++ gregoire.dla-1866.wml	2019-08-02 11:47:45.878195465 +0800
@@ -20,12 +20,12 @@
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2019-13012";>CVE-2019-13012</a>
 
-<p>Le dorsal de réglages de fichier clef dans GNOME GLib (c'est-à-dire glib2.0)
+<p>Le dorsal de réglages de fichier de clefs dans GNOME GLib (c'est-à-dire glib2.0)
 avant 2.60.0 créait des répertoires en utilisant
 g_file_make_directory_with_parents (kfsb->dir, NULL, NULL) et des fichiers en
 utilisant g_file_replace_contents (kfsb->file, contents, length, NULL, FALSE,
 G_FILE_CREATE_REPLACE_DESTINATION, NULL, NULL, NULL). Par conséquent, il ne
-restreignait pas correctement les permissions de répertoire (et fichier). Pour
+restreignait pas correctement les permissions de répertoire (et de fichier). Pour
 les répertoires, la permission 0777 était utilisée, pour les fichiers, les
 permissions par défaut étaient utilisées. Ce problème est similaire à
 <a href="https://security-tracker.debian.org/tracker/CVE-2019-12450";>CVE-2019-12450</a>.</p></li>
--- dla-1867.wml	2019-08-02 11:48:28.770019497 +0800
+++ gregoire.dla-1867.wml	2019-08-02 11:44:47.423359798 +0800
@@ -12,13 +12,13 @@
 
 <p>Une attaque par canal auxiliaire basée sur le cache à l'encontre de
 l'implémentation de EAP-pwd : un attaquant ayant la possibilité d'exécuter du
-code sans droit sur la machine cible (y compris par exemple du code javascript
+code sans droits sur la machine cible (y compris par exemple du code javascript
 dans un navigateur sur un ordiphone) durant la négociation de connexion pourrait
 déduire suffisamment d'informations pour découvrir le mot de passe dans une
 attaque par dictionnaire.</p>
 
 <p>Ce problème a été seulement très partiellement tempéré en réduisant les
-différences mesurables d’horodatage lors des opérations de clef privée. Plus de
+différences mesurables d’horodatage lors d'opérations sur la clef privée. Plus de
 travail est nécessaire pour supprimer complètement cette vulnérabilité.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2019-9497";>CVE-2019-9497</a>
@@ -29,7 +29,7 @@
 permettraient de réussir des échanges d'authentification EAP-pwd sans que
 l'attaquant ait à connaître le mot de passe. Cela n'aboutit pas à ce que
 l'attaquant soit capable d'obtenir la clé de session, de réussir l'échange de
-clé suivant et d'accéder au réseau.</p></li>
+clé subséquent puis d'accéder au réseau.</p></li>
 
 <li><a href="https://security-tracker.debian.org/tracker/CVE-2019-9498";>CVE-2019-9498</a>
 

Reply to: