Re: [RFR2] wml://security/2016/dla-14{0,1,2,3,5}.wml

2017-08-17 Par sujet Baptiste Jammet 

Bonjour,

Le 17/08/2017 11:19, jean-pierre giraud a écrit :

Le 17/08/2017 à 10:29, JP Guillonneau a écrit :

le lundi 14 août 18:47, Baptiste Jammet a écrit :



URL au féminin ?



http://www.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=26515499
http://jargonf.org/wiki/URL


Mais https://fr.wikipedia.org/wiki/URL
(ce n'est pas un argument d'autorité…)

Je suis plutôt prêt à suivre la fiche de l'oqlf et essayer de m'en 
tenir

au masculin, voire de corriger à l'occasion les occurrences féminines,
même si je comprends parfaitement le choix du féminin (url = adresse) 
et

même des arguments d'euphonisme : une url sonnerait mieux qu'un url.


Il me semble que le féminin est utilsé majoritairement (voire 
exclusivement) sur le site web et dans nos traductions.

C'est la raison de ma préférence (rester homogène).
(Ou alors on passe tout au masculin, mais c'est pas moi qui m'y colle !)

Baptiste

Re: [RFR2] wml://security/2016/dla-14{0,1,2,3,5}.wml

2017-08-17 Par sujet jean-pierre giraud 
Le 17/08/2017 à 10:29, JP Guillonneau a écrit :
> Bonjour,
> 
> le lundi 14 août 18:47, Baptiste Jammet a écrit :
> 
>> URL au féminin ?
> 
> http://www.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=26515499
> http://jargonf.org/wiki/URL
> 
> D’autres avis ?
> 
> Amicalement.
> 
> --
> Jean-Paul
> 
Je suis plutôt prêt à suivre la fiche de l'oqlf et essayer de m'en tenir
au masculin, voire de corriger à l'occasion les occurrences féminines,
même si je comprends parfaitement le choix du féminin (url = adresse) et
même des arguments d'euphonisme : une url sonnerait mieux qu'un url.
jipege

Re: [RFR2] wml://security/2016/dla-14{0,1,2,3,5}.wml

2017-08-17 Par sujet JP Guillonneau 
Bonjour,

le lundi 14 août 18:47, Baptiste Jammet a écrit :

>URL au féminin ?

http://www.gdt.oqlf.gouv.qc.ca/ficheOqlf.aspx?Id_Fiche=26515499
http://jargonf.org/wiki/URL

D’autres avis ?

Amicalement.

--
Jean-Paul

Re: [RFR2] wml://security/2016/dla-14{0,1,2,3,5}.wml

2017-08-14 Par sujet Baptiste Jammet 
Bonjour, 

Dixit JP Guillonneau, le 12/08/2017 :

>D’autres commentaires ?

URL au féminin ?

Baptiste
--- 0ad5.dla-143.wml	2017-08-14 18:45:02.783037147 +0200
+++ ./0ad5.dla-143-bj.wml	2017-08-14 18:46:18.414155239 +0200
@@ -47,13 +47,13 @@
 
 Django dépend des saisies d’utilisateur dans certains cas (par exemple,
 django.contrib.auth.views.login() et i18n) pour rediriger l’utilisateur vers
-un URL lors d’un succès. Les vérifications de sécurité pour ces
+une URL lors d’un succès. Les vérifications de sécurité pour ces
 redirections (à savoir django.util.http.is_safe_url()) ne retirent pas les
-espaces de début dans les URL testés et de cette façon considèrent les URL
-tels que « \njavascript:... » sûrs. Si un développeur se fie à is_safe_url()
-pour fournir des cibles de redirections fiables et met un tel URL dans un
+espaces de début dans les URL testées et de cette façon considèrent les URL
+telles que « \njavascript:... » sûrs. Si un développeur se fie à is_safe_url()
+pour fournir des cibles de redirections fiables et met une telle URL dans un
 lien, elles pourraient subir une attaque XSS. Ce bogue n’affecte pas
-actuellement Django, puisque cet URL est seulement mis dans l’en-tête de
+actuellement Django, puisque cette URL est seulement mis dans l’en-tête de
 réponse Location et les navigateurs paraissent ignorer JavaScript ici.
 
 https://security-tracker.debian.org/tracker/CVE-2015-0221;>CVE-2015-0221
@@ -72,7 +72,7 @@
 n’est pas renforcé lors d’une utilisation en production, et devrait être
 seulement utilisée comme aide au développement. C’est peut-être le moment
 d’analyser votre projet et servir vos fichiers en production en utilisant un
-vrai serveur web frontal si vous ne le faites déjà.
+vrai serveur web frontal si vous ne le faites pas déjà.
 
 
 


pgpvBGUR7iXXW.pgp
Description: OpenPGP digital signature

[RFR2] wml://security/2016/dla-14{0,1,2,3,5}.wml

2017-08-12 Par sujet JP Guillonneau 
Bonjour,

le vendredi 11 août 19:08, jean-pierre giraud a écrit :

>Quelques suggestions.
Merci, intégrées.
D’autres commentaires ?

Amicalement.

--
Jean-Paul
#use wml::debian::translation-check translation="1.3" maintainer="Jean-Paul Guillonneau"
Mise à jour de sécurité pour LTS

Plusieurs vulnérabilités ont été corrigées dans rpm :



https://security-tracker.debian.org/tracker/CVE-2014-8118;>CVE-2014-8118

Correction d’un dépassement d’entier permettant à des attaquants distants
d’exécuter du code arbitraire.

https://security-tracker.debian.org/tracker/CVE-2013-6435;>CVE-2013-6435

Empêchement pour des attaquants distants d’exécuter du code arbitraire à
l’aide de fichiers RPM contrefaits.

https://security-tracker.debian.org/tracker/CVE-2012-0815;>CVE-2012-0815

Correction d’un déni de service et d’une exécution possible de code à
l’aide d’une valeur négative pour l’emplacement de zone dans des fichiers RPM
contrefaits.

https://security-tracker.debian.org/tracker/CVE-2012-0060;>CVE-2012-0060
et https://security-tracker.debian.org/tracker/CVE-2012-0061;>CVE-2012-0061

Empêchement d’un déni de service (plantage) et éventuellement de
l’exécution de code arbitraire à l’aide d’une balise de zone non valable dans
des fichiers RPM.



Nous vous recommandons de mettre à jour vos paquets rpm.
Pour Debian 6 Squeeze, ces problèmes ont été corrigés dans la
version 4.8.1-6+squeeze2 de rpm.


# do not modify the following line
#include "$(ENGLISHDIR)/security/2015/dla-140.data"
# $Id : dla-140.wml,v 1.3 2016/04/08 20:32:23 djpig Exp $
#use wml::debian::translation-check translation="1.3" maintainer="Jean-Paul Guillonneau"
Mise à jour de sécurité pour LTS

Une vulnérabilité a été corrigée dans la bibliothèque libksba de prise en
charge de X.509 et de CMS :



https://security-tracker.debian.org/tracker/CVE-2014-9087;>CVE-2014-9087

Correction d’un dépassement de tampon dans ksba_oid_to_str, signalé par
Hanno Böck.



Pour Debian 6 Squeeze, ce problème a été corrigé dans la
version 1.0.7-2+deb6u1 de libksba.
Nous vous recommandons de mettre à jour vos paquets libksba.


# do not modify the following line
#include "$(ENGLISHDIR)/security/2015/dla-141.data"
# $Id: dla-141.wml,v 1.2 2017/08/12 12:05:55 jptha-guest Exp $
#use wml::debian::translation-check translation="1.3" maintainer="Jean-Paul Guillonneau"
Mise à jour de sécurité pour LTS

Plusieurs vulnérabilités ont été découvertes dans Privoxy, un serveur
mandataire (Proxy) HTTP qui améliore la confidentialité :



https://security-tracker.debian.org/tracker/CVE-2015-1031;>CVE-2015-1031,
CID66394 :

unmap() : empêchement d’une utilisation de mémoire après libération si le
mappage consiste en un seul item.

https://security-tracker.debian.org/tracker/CVE-2015-1031;>CVE-2015-1031,
CID66376 et CID66391 :

pcrs_execute() : régler systématiquement *result à NULL en cas d’erreurs.
Cela devrait rendre une utilisation de mémoire après libération dans
l’appelant moins probable.

https://security-tracker.debian.org/tracker/CVE-2015-1381;>CVE-2015-1381:

Correction de plusieurs erreurs de segmentation et fuites de mémoire dans
le code de pcrs.

https://security-tracker.debian.org/tracker/CVE-2015-1382;>CVE-2015-1382:

Correction de lecture non valable pour empêcher des plantages potentiels.



Nous vous recommandons de mettre à jour vos paquets privoxy.
Pour Debian 6 Squeeze, ces problèmes ont été corrigés dans la
version 3.0.16-1+deb6u1 de privoxy.


# do not modify the following line
#include "$(ENGLISHDIR)/security/2015/dla-142.data"
# $Id: dla-142.wml,v 1.2 2017/08/12 12:05:55 jptha-guest Exp $
#use wml::debian::translation-check translation="1.3" maintainer="Jean-Paul Guillonneau"
Mise à jour de sécurité pour LTS

Plusieurs problèmes de sécurité ont été découverts dans Django :
https://www.djangoproject.com/weblog/2015/jan/13/security/;>
https://www.djangoproject.com/weblog/2015/jan/13/security/

Pour Debian 6 Squeeze, ils ont été corrigés dans la
version 1.2.3-3+squeeze12 de python-django. Voici ce que les développeurs
amont ont à dire à propos de ces problèmes :



https://security-tracker.debian.org/tracker/CVE-2015-0219;>CVE-2015-0219

– Usurpation d’en-tête WSGI à l’aide d’une combinaison de tirets bas et
de tirets

Lorsque des en-têtes HTTP sont placés dans la fonction environ de
WSGI, ils sont standardisés en les convertissant en majuscules, en
convertissant tous les tirets en tirets bas et en ajoutant le préfixe HTTP_.
Par exemple, un en-tête X-Auth-User devient HTTP_X_AUTH_USER dans la fonction
environ WSGI (et par conséquent aussi dans le dictionnaire
request.META de Django).

Malheureusement, cela signifie que la fonction environ de WSGI ne
faisait pas de distinction entre les en-têtes contenant des tirets et ceux
contenant des tirets bas : X-Auth-User et X-Auth_User deviennent tous les deux