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

Re: État de sécurité des navigateurs web



On 2013-03-12 17:39:54 +0100, Sébastien NOBILI wrote:
> Le mardi 12 mars 2013 à 17:22, Vincent Lefevre a écrit :
> > On 2013-03-12 11:24:34 +0100, Sébastien NOBILI wrote:
> > > Sans prendre en considération le contrat social et le caractère
> > > non-libre des noms et logos, si Debian fournissait un Firefox tel
> > > quel, le travail de suivi des versions amont serait simplifié, mais
> > > il serait alors impossible à la stable de rester stable. En effet,
> > > aucune garantie de la part de Mozilla d'apporter des correctifs sur
> > > d'anciennes versions et Debian devrait choisir entre :
> > >     - avoir une version de Firefox touchée par des problèmes de sécurités,
> > >     - faire évoluer la version de Firefox, mais adieu stabilité.
> > 
> > Pas d'accord. Les versions ESR pas trop vieilles (ce qui n'est pas le
> > cas de la 10.x, qui n'est plus maintenue, je crois bien) sont faites
> > pour éviter ce genre de choix.
> 
> Oui et non :
>     « La fondation assure la sécurité de la version pendant un an,
>     avant qu'une nouvelle version venant de la branche stable serve
>     d'appui pour le cycle suivant. Un chevauchement de 12 semaines
>     est prévue entre 2 versions ESR. »
>     (https://fr.wikipedia.org/wiki/Firefox#Firefox_ESR)
> 
> C'est compatible si Debian sort une version stable tous les ans, or
> une Debian stable n'arrive que quand elle est prête, dans la
> pratique c'est à peu près tous les deux ou trois ans.

Disons qu'avec la ESR 17, on aurait moins de problèmes qu'avec
la ESR 10. Cela demandait de casser la règle du freeze pour ce
cas particulier, mais pour une bonne raison. En plus, je ne pense
pas que trouver suffisamment de personnes pour tester aurait posé
problème. Et ce n'est pas non plus comme si la ESR 17 était sortie
juste quelques semaines avant la nouvelle release de Debian. Cela
fait déjà 3 mois qu'elle aurait pu être testée, avec les corrections
éventuelles nécessaires.

Je me demande aussi pourquoi le freeze est si long. Si la raison
est la correction des bugs RC, il aurait mieux vallu le faire
avant le freeze. En gros, freeze when ready.

-- 
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


Reply to: