Bonjour, le jeudi 17 août 12:06, 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é…) Larousse donne les deux genres : http://www.larousse.fr/dictionnaires/francais/URL/80723 http://www.larousse.fr/dictionnaires/anglais-francais/URL/621983 >> 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. « une URL » gagne 65 à 4 contre « un URL » dans les pages du site. >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 !) Pour homogénéité, application du correctif. Merci d’avance pour vos dernières relectures. Amicalement. -- Jean-Paul
#use wml::debian::translation-check translation="1.3" maintainer="Jean-Paul Guillonneau" <define-tag description>Mise à jour de sécurité pour LTS</define-tag> <define-tag moreinfo> <p>Plusieurs problèmes de sécurité ont été découverts dans Django : <a href="https://www.djangoproject.com/weblog/2015/jan/13/security/";> https://www.djangoproject.com/weblog/2015/jan/13/security/</a></p> <p>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 :</p> <ul> <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0219";>CVE-2015-0219</a> <p>â Usurpation dâen-tête WSGI à lâaide dâune combinaison de tirets bas et de tirets</p> <p>Lorsque des en-têtes HTTP sont placés dans la fonction <q>environ</q> 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 <q>environ</q> WSGI (et par conséquent aussi dans le dictionnaire request.META de Django).</p> <p>Malheureusement, cela signifie que la fonction <q>environ</q> 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 HTTP_X_AUTH_USER. Cela signifie que si un en-tête est utilisé dans un but sécuritaire (par exemple, transmettre des informations dâauthentification à partir dâun mandataire frontal), même si le mandataire retire soigneusement toute valeur entrante pour X-Auth-User, un attaquant pourrait être capable de fournir un en-tête X-Auth_User (avec un tiret bas) et de contourner cette protection.</p> <p>Dans le but dâempêcher de telles attaques, à la fois Nginx et Apache 2.4+ retirent par défaut tous les en-têtes contenant des tirets bas pour les requêtes entrantes. Le serveur incorporé en développement de Django fait maintenant la même chose. Celui-ci nâest pas recommandé en production, mais uniformiser le comportement des serveurs de production courants réduit les possibilités de changement de comportement lors de déploiements.</p></li> <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0220";>CVE-2015-0220</a> <p>â Attaques de script intersite (XSS) possibles à lâaide de redirections dâURL fournies par des utilisateurs</p> <p>Django dépend des saisies dâutilisateur dans certains cas (par exemple, django.contrib.auth.views.login() et i18n) pour rediriger lâutilisateur vers une URL lors dâun <q>succès</q>. 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ées et de cette façon considèrent les URL telles que « \njavascript:... » sûres. 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 cette URL est seulement mise dans lâen-tête de réponse Location et les navigateurs paraissent ignorer JavaScript ici.</p></li> <li><a href="https://security-tracker.debian.org/tracker/CVE-2015-0221";>CVE-2015-0221</a> <p>â Attaque par déni de service contre django.views.static.serve</p> <p>Dans les anciennes versions de Django, la vue django.views.static.serve() lit les fichiers quâil distribue une ligne à la fois. Par conséquent, un gros fichier sans nouvelle ligne pourrait conduire dans une utilisation de la mémoire égale à la taille de ce fichier. Un attaquant pourrait exploiter cela et lancer une attaque par déni de service en demandant de nombreux gros fichiers. Cette vue maintenant lit le fichier par morceaux pour prévenir dâun usage excessif de la mémoire.</p> <p>Notez, cependant, que cette vue a toujours transmis un avertissement qui 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 pas déjà .</p></li> </ul> <p>Notez que la version de Django utilisée dans Debian 6 Squeeze nâétait pas affectée par <a href="https://security-tracker.debian.org/tracker/CVE-2015-0222";>CVE-2015-0222</a> (déni de service de base de données avec ModelPlusieursChoiceField) puisque cette fonction nâexiste pas dans cette version.</p> <p>Pour Debian 6 <q>Squeeze</q>, ces problèmes ont été corrigés dans la version 1.2.3-3+squeeze12 de python-django.</p> </define-tag> # do not modify the following line #include "$(ENGLISHDIR)/security/2015/dla-143.data" # $Id: dla-143.wml,v 1.3 2017/08/18 08:56:00 jptha-guest Exp $
