Tu mélange des choix plutôt incongrus avec des trucs plus intéressants... Ce qui est important pour la sécurité d'une distribution c'est son processus de qualité. Ont-t'ils des gens qui ne sont là que pour la sécurité ? Que font-t'ils ? Quel est le temps de propagation des fix upstream ? Y a t'il des audits réguliers ? C'est des sujets bien plus objectifs que de choisir au doigts mouillé si une faille plus ou moins médiatisée. L’absence de faille est un leurre. Si un logiciel n'a jamais eu de faille, comment savoir ce qu'il va se passer quand il y en aura une ? Est-ce que la fierté des mainteneurs ne les empêchera pas de l'annoncer ? Est-ce qu'il y a un bug bounty sur le logiciel ou la distribution ?
Les processus humains sont objectivement comparables et c'est bien.
Une bibliothèque de remplacement plus robuste qu’OpenSSL, par exemple, peut être un critère.
Pourquoi pour OpenSSL et pas OpenSSH, le shell par défaut ou je ne sais quoi d'autres. Tu montre des arguments très emprunt du marketing classique (systemd, openssl,...). C'est dangereux de faire des choix qu'on espère fiables sur des bases aussi fragiles. Pour OpenSSL la façon de l'utiliser peut avoir un impact. Par exemple OpenBSD n'a pas attendu la fameuse faille pour ne pas laisser OpenSSL décoder les certificats ASN1 si je ne m'abuse. Pour être un peu plus fiable avec ton approche par logiciel au doigt mouillé il faudrait lister tous les paquets installé et regarder les différences ce qui n'est pas vraiment tenable
[^] # Re: Sécurité
Posté par barmic . En réponse au journal Lancer un programme sans accès au réseau, merci les espaces de noms réseaux. Évalué à 2.
Tu mélange des choix plutôt incongrus avec des trucs plus intéressants... Ce qui est important pour la sécurité d'une distribution c'est son processus de qualité. Ont-t'ils des gens qui ne sont là que pour la sécurité ? Que font-t'ils ? Quel est le temps de propagation des fix upstream ? Y a t'il des audits réguliers ? C'est des sujets bien plus objectifs que de choisir au doigts mouillé si une faille plus ou moins médiatisée. L’absence de faille est un leurre. Si un logiciel n'a jamais eu de faille, comment savoir ce qu'il va se passer quand il y en aura une ? Est-ce que la fierté des mainteneurs ne les empêchera pas de l'annoncer ? Est-ce qu'il y a un bug bounty sur le logiciel ou la distribution ?
Les processus humains sont objectivement comparables et c'est bien.
Pourquoi pour OpenSSL et pas OpenSSH, le shell par défaut ou je ne sais quoi d'autres. Tu montre des arguments très emprunt du marketing classique (systemd, openssl,...). C'est dangereux de faire des choix qu'on espère fiables sur des bases aussi fragiles. Pour OpenSSL la façon de l'utiliser peut avoir un impact. Par exemple OpenBSD n'a pas attendu la fameuse faille pour ne pas laisser OpenSSL décoder les certificats ASN1 si je ne m'abuse. Pour être un peu plus fiable avec ton approche par logiciel au doigt mouillé il faudrait lister tous les paquets installé et regarder les différences ce qui n'est pas vraiment tenable