Qui est derrière le référentiel Webtatic et lui faites-vous confiance

Le référentiel Webtatic contient de nombreux packages utiles pour CentOS et RedHat. Cependant, le référentiel est très opaque et j'ai du mal à trouver des informations sur qui est derrière, à part "Andrew Thompson", connu sous le nom d'Andy ici.

Il semble faire un excellent travail en fournissant tous ces packages utiles. J'ai besoin d'utiliser le référentiel sur des serveurs d'entreprise en direct et l'utilisation de référentiels non officiels déclenche immédiatement une alarme en moi.

• S'agit-il d'un référentiel individuel?
• Est-il soutenu par une entreprise?
• Il semble exister depuis quelques années maintenant, mais qu'en est-il de demain? (à part l'astéroïde géant qui peut tous nous essuyer)
• Est-il sécurisé? Je ne veux pas ensuite yum updatetélécharger un cheval de Troie.
• À quelle vitesse les correctifs de sécurité sont-ils déployés des packages fournis? ....

Les commentaires des administrateurs CentOS / RedHat réels seront grandement appréciés.

Merci d'avance

À mes débuts en tant qu'administrateur Linux il y a 8 ans, j'utilisais un référentiel tiers populaire pour mettre à niveau ma pile LAMP. Il était dirigé par une seule personne. L'une des principales raisons était que les développeurs me faisaient pression pour une version de PHP plus récente que celle fournie avec RHEL 5. Cela a fini par me mordre.

La personne a abandonné les référentiels, donc je n'obtenais plus de mises à jour de sécurité, mais je ne pouvais pas non plus supprimer tous les nouveaux packages et revenir aux packages RHEL en raison de la version RHEL de PHP provenant d'une branche trop ancienne. Le passage à la pile LAMP de ce référentiel a touché au moins une demi-douzaine de packages ou plus. Donc, maintenir ces packages et les recompiler tous à la main de temps en temps serait un PITA majeur.

Vous perdez également la possibilité d'utiliser les avis de sécurité du fournisseur du système d'exploitation concernant les vulnérabilités CVE pour déterminer si votre système est ou non vulnérable à un certain exploit pour ces packages. Cela s'est avéré être un problème majeur pour moi des années plus tard, même si je ne l'avais jamais prévu à l'époque.

Donc, en plus d'avoir confiance dans l'intégrité et les compétences techniques des responsables, vous devez vous demander si vous leur faites confiance pour ne pas passer à un nouvel emploi qui ne leur permettra pas de maintenir le référentiel, ou de se marier et d'avoir des enfants et non plus avoir le temps, etc ....

Depuis lors, je suis très nerveux à l'idée d'utiliser des référentiels tiers, en particulier ceux qui ne sont gérés que par une seule personne.

La question n'est pas si nous faisons confiance à Andy, c'est si vous faites confiance à Andy.

Je ne connais pas le référentiel mais le bouton don suggère un effort personnel. N'hésitez pas à contribuer si cela a de la valeur pour vous.

Les packages semblent être signés GnuPG, il est donc possible de vérifier avec une certaine certitude que les packages sont authentiques. Vous pouvez également vérifier s'il est sur la toile de confiance.

En ce qui concerne la qualité ou la sécurité, il vaut mieux que quelqu'un d'autre regarde comment fonctionne le référentiel. Ça pourrait être toi. Abonnez-vous aux avis de sécurité en amont et vérifiez s'ils sont affectés. Évaluez les packages comme le ferait un critique pour Fedora.

Si la continuité de ces packages est importante pour vous, acquérez des compétences similaires. Apprenez l'emballage ou embauchez quelqu'un qui le peut.

Remi est la norme pour les dernières versions de PHP pour RHEL. Il est une source établie depuis longtemps et fiable pour les packages RPM qui est activement maintenue et comprend autant de packages pertinents que possible.

La source webtatique est inconnue et non fiable. Il ne devrait pas du tout être utilisé.

Je l'ai trouvé fonctionnant sur un système hérité. Il y avait une grave fuite de mémoire. Je l'ai remplacé par Remi, exactement la même version PHP et tout à coup tout se passe bien. Je ne pense pas que ce soit même une compilation stable.

En général, à moins que vous ne sachiez qu'il existe une fonctionnalité dont vous avez réellement besoin et dont vous ne pouvez pas vous passer (comme beaucoup de gens penseront qu'ils ne peuvent pas ... jusqu'à ce que ce soit un choix entre `` ancien '' ou rien), alors restez avec les packages du fournisseur.

Apprenez à vos webdevs pourquoi une branche n'est pas un instantané stagnant, et montrez-leur - PHP en est un excellent exemple - comment le rebasage en amont apporte beaucoup plus de bugs; et comment, dans de nombreux cas, le temps de réponse pour un backport autour d'un problème de sécurité est en fait plus rapide et plus fiable fourni par une distribution dans leur branche maintenue (car c'est la priorité et le travail de quelqu'un) que dans la version OEM en amont.

Vous êtes peut-être celui qui réussit réellement, et vous devez à nous tous d'essayer ;-)