bonjour,
on avait rapidement abordé le sujet dans un autre fil mais je me pose une question.
Est ce qu’il faut privilégier les dépôts stable de debian qui présentent des version parfois limite obsolète (php5.4)
ou alors utiliser des dépots non officiel avec des paquets à jour (aller sur la page de téléchargement de php par exemple)
niveau sécurité j’imagine que debian ne sécurise pas php au même niveau que l’équipe de php, vous en pensez quoi?
Il vaut mieux utiliser les dépôts testing ou unstable de Debian 
Tu as l’assurance qu’un minimum d’audit du code a été effectué, et qu’il n’y a pas de backdoor volontaire de la part de l’équipe de dev de PHP (par exemple).
sauf qu’il n’y a pas de mise à jour de sécurité pour les paquets non stable…
et puis php est opensource il me semble non?
[quote=“vger”]sauf qu’il n’y a pas de mise à jour de sécurité pour les paquets non stable…
et puis php est opensource il me semble non?[/quote]
Il n’y a pas de dépôts de mise à jour car les paquets sont régulièrement mis à jour (pour ce qui concerne la partie ‘unstable’).
Maintenant je ne préconisai surement pas pour des clients l’utilisation de version compilé à la mano autrement que pour moi et a condition de suivre de très près les alertes de sécurité de ces paquets.
PHP Opensource oui mais je me casserai pas la tête pour des clients (ou pour moi même à compiler ça à chaque fois qu’un correctifs est mise à disposition, c’est beaucoup trop contraignant).
A la différence de Windows qui n’a pas le choix tu peux utiliser les dépôts de Debian, quel est la raison exact de vouloir passer en dehors de ce confort ?
Si c’est une obligation d’une version bien précise faut vraiment pesée le pour et le contre car franchement suivre PHP et tous les paquets connexe qui vont avec au niveau sécurité c’est ultra lourd pour simplement faire tourner du Joomla ou du Drupal (et dans ce cas le pinning est une meilleur option de toute façon).
Maintenant les dépôts dotdeb, je ne les recommande pas et en générale je préfère lorsque c’est faisable faire du pinning lorsque c’est une réelle obligation.
Bien entendu je n’utilise pas non plus de PPA (sauf pour un cas bien précis où je suis sûr de mon coup et que ça me facilite la vie).
Je ne maitrise pas le sujet mais de mon point de vue tout bête je me dis :
"Php sors toujours de nouvelles mise à jour et de nouvelles versions en conseillant la version la plus récente à chaque fois et à chaque fois parlent d’une nouvelle faille ou vulnérabilité corrigé. Donc si je veux un script php sûr, au delà du code il y a peut être aussi la version php à adopter.
mais voilà, debian fais totalement le contraire au nom de la sécurité et/ou stabilité. Ils restent accroché à d’ancien paquets… A mon avis, comme c’est parti et vu que jessie est déjà gelée, le temps que la version d’après jessie deviennent stable on en sera avec une version php obsolète et non supportée…
C’est le même but mais c’est l’opposé… je sais pas si rester avec les paquets officiel serait aussi sûr que d’utiliser la version php la plus à jour…
Je ne maitrise pas le sujet mais de mon point de vue tout bête je me dis :
"Php sors toujours de nouvelles mise à jour et de nouvelles versions en conseillant la version la plus récente à chaque fois et à chaque fois parlent d’une nouvelle faille ou vulnérabilité corrigé. Donc si je veux un script php sûr, au delà du code il y a peut être aussi la version php à adopter.
mais voilà, debian fais totalement le contraire au nom de la sécurité et/ou stabilité. Ils restent accroché à d’ancien paquets… A mon avis, comme c’est parti et vu que jessie est déjà gelée, le temps que la version d’après jessie deviennent stable on en sera avec une version php obsolète et non supportée…
C’est le même but mais c’est l’opposé… je sais pas si rester avec les paquets officiel serait aussi sûr que d’utiliser la version php la plus à jour…[/quote]
Je sais pas comment ça se passe exactement, mais si une faille est decouverte dans une ancienne version de php qui est dans les depots stable de debian, j’imagine que les mainteneurs des paquets debian s’efforcent de corriger la faille et sortent un patch ou quelque chose comme ça qui sera appliqué au prochain apt-get upgrade.
Debian a une réputation serieuse et je ne les vois pas laisser volontairement une faille comme ça, alors que debian est installé sur de nombreux serveurs.
et pourtant, il suffit de regarder la version apache…
debian stable en est à la realease 2.2 version 2.2.22: Released January 31, 2012
actuellement on a les release 2.2 2.3 et 2.4
sauf que la 2.2 on en est à la version 2.2.29: Released September 1, 2014
alors soit il n’y a pas eu de mises à jour de sécurité dans les versions
2.2.29: Released September 1, 2014
2.2.27: Released March 18, 2014
2.2.26: Released November 16, 2013
2.2.25: Released July 9, 2013
2.2.24: Released February 25, 2013
2.2.23: Released September 13, 2012
Soit Debian fait le travail d’apache en parallèle d’apache…
Soit Debian s’occupe du sytème d’exploitation et pas du logiciel…
Franchement je sais pas
Note : Debian à une réputation de stabilité, ce qui est indéniable. Mais ca ne rime pas forcément avec sécurité…
La derniere mise à jour de securité date de 2014 debian.org/security/2014/dsa-2989
voir aussi : debian.org/security/
d’accord donc si je comprends bien debian à ses propres fork des logiciels qu’il propose et en assure la sécurité et la stabilité en parallèle du logiciel original…
vu comme ca oui ce n’est pas plus mal de rester avec les paquets stables…
[quote=“vger”]d’accord donc si je comprends bien debian à ses propres fork des logiciels qu’il propose et en assure la sécurité et la stabilité en parallèle du logiciel original…
vu comme ca oui ce n’est pas plus mal de rester avec les paquets stables…[/quote]
Non pas des forks, mais il n’utilise pas la même numérotation simplement que le projet initiale, il n’y a qu’a regarder du côté effectivement des dépôts de sécurité.
Juste pour information dernière version ne rime pas avec ‘plus sécurisée’.
Avant qu’une faille ne soient découverte il faut généralement du temps.
Si on prend à la lettre se que que tu pense il serait alors bien plus sécurisé d’utiliser un système en rolling relaese, ce qui est totalement à l’encontre de ce que les ‘adminsys’ cherchent pour des machines en production.
Le but n’est pas de trifouiller tout le temps son serveur mais bien au contraire de pouvoir se concentrer au maximum sur le contenu.
Rassure toi 95% des failles viennent des CMS et des bourdes faites sur le serveur et non des failles de sécurité sur les composants de ton système (mis à part Bind9 et Openssl, très peux de composants se sont vue troués au points de compromettre le serveur).
Comme je l’ai déjà expliqué la montée en version doit avant tout est une obligation lié à un utilitaire/application indispensable plus qu’a une idée de renforcer la sécurité et/ou motivé par un besoin impériale d’une fonctionnalité non présente dans les version antérieur.
Salut,
Il me semble qu’à travers de ta quête, tu as oublié de mentionner un élément déterminant.
Un serveur chez online, prochainement en production, si ce n’est pas déjà le cas.
Qui dit serveur en prod dit [mono]Debian[/mono] et dépôts [mono]Stable[/mono], un point c’est tout.
Je ne suis pas sûr d’être rassuré… 
de toute façon faire un site from scratch est plus amusant.
En tout cas merci à vous. Je peux me concentrer sur l’installation de mon serveur ^^