Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique
Donc non, pas d'inquiétude côté upstream apparemment
> Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.
Peut-être, mais même si elle connaît seule les paquets, toute organisation est finalement monolithique.
Pour cette idée de la vérification de signature, je signalais juste qu'il était possible de mettre en ligne une copie (donc sur des serveurs non gérés par la distribution) des signatures de packages, copie elle-même signée par un tiers (celui qui gère ces serveurs hors distribution), copie qui ne mettrait à jour sa signature locale d'un package que lorsque celui-ci a été observé par un humain (de la même organisation qui gère ces serveurs hors distribution) et que l'humain à constaté que cette mise à jour a été annoncée d'une manière ou d'une autre : soit sur les listes de sécurité de la distribution, soit via le processus habituel (genre le développeur qui renseigne proprement un changelog, le patch associé, le mail sur la liste devel etc.)
D'ici à ce qu'un pirate puisse passer ce _processus_ qui fait finalement appels aux habitudes de la communauté, il faudra de véritables bourdes majeures, et cela peut donc rendre plus robuste l'infrastructure de distribution.
Cela reprend le classique paradigme : pirater un système au hasard est très facile, pirater un système particulier infiniment plus difficile.
Donc pirater un jour quelque chose dont il advient qu'il s'agit d'un serveur principal de distribution, c'est une chose, pirater ensuite l'infrastructure tierce qui co-valide les signatures, c'est une toute autre paire de manches.
[^] # Re: Diversité, diversité :)
Posté par Benjamin (site web personnel) . En réponse au journal Intrusion sur les serveurs Fedora/Red Hat. Évalué à 3.
Ayant déjà vécu ce genre de problème avec d'autres softs upstream, on a généralement des infos sur les listes de sécurité des différentes distributions quasi en même temps : si redhat trouve un problème grâve dans, mettons, openssl, ils préviennent openssl qui prévient à son tour les distributions majeures, c'est assez classique
Donc non, pas d'inquiétude côté upstream apparemment
> Ça n'a pas d'intérêt. C'est la distribution qui connait les paquets.
Peut-être, mais même si elle connaît seule les paquets, toute organisation est finalement monolithique.
Pour cette idée de la vérification de signature, je signalais juste qu'il était possible de mettre en ligne une copie (donc sur des serveurs non gérés par la distribution) des signatures de packages, copie elle-même signée par un tiers (celui qui gère ces serveurs hors distribution), copie qui ne mettrait à jour sa signature locale d'un package que lorsque celui-ci a été observé par un humain (de la même organisation qui gère ces serveurs hors distribution) et que l'humain à constaté que cette mise à jour a été annoncée d'une manière ou d'une autre : soit sur les listes de sécurité de la distribution, soit via le processus habituel (genre le développeur qui renseigne proprement un changelog, le patch associé, le mail sur la liste devel etc.)
D'ici à ce qu'un pirate puisse passer ce _processus_ qui fait finalement appels aux habitudes de la communauté, il faudra de véritables bourdes majeures, et cela peut donc rendre plus robuste l'infrastructure de distribution.
Cela reprend le classique paradigme : pirater un système au hasard est très facile, pirater un système particulier infiniment plus difficile.
Donc pirater un jour quelque chose dont il advient qu'il s'agit d'un serveur principal de distribution, c'est une chose, pirater ensuite l'infrastructure tierce qui co-valide les signatures, c'est une toute autre paire de manches.