> Faux, archi faux. C'est un moyen pour toi de vérifier, plus vite que tu ne pourrais le faire sans, des propriétés sur ton programme. Ça n'a rien à voir avec une signature. Si ton certificat te permet de vérifier faclement que y'a pas de bufferoverflow, tu peux avoir sur ce point une confiance bien plus grande que la signature de Debian, qui dit elle "jusque là, on en a pas trouver, donc on vous file le truc".
???
Pas compris... En quoi TCPA garantit-il qu'il n'y a pas de buffer overflow? C'est le revendeur du programme qui l'affirme mais il est logé à la même enseigne que le revendeur Debian: il a produit un code et il doit vérifier que celui-ci ne comporte pas de bug ou de faille de sécurité. A ma connaissance, il n'existe pas aujourd'hui d'outils magique qui détecte automatiquement tous les buffers overflows et toutes les failles de sécurité. Les outils tels que purify sont encore bien imparfaits, et ne permettent que l'accélération de la recherche de bug, mais en aucun ils ne permettent une éradication systématique des fautes de programmation. Donc signature TCPA ou sceau MD5 c'est pareil: ça te dit que le programme que tu as est le même que celui que le programmeur voulait distribuer, et que tous les bugs que le programmeur a réussi à trouver ont été corrigés.
La signature TCPA n'apporte pas plus que la signature MD5 d'un paquet Debian du point de vue de l'utilisateur. Par contre vis-à-vis du revendeur du programme la différence est notoire car dans le 1er cas les éditeurs peuvent décider que si tu utilise un programme sans avoir la bonne signature alors le programme fonctionne en mode dégradé, voire pas du tout.
A part ça la signature des paquets n'est absolument pas une garantie de sécurité du système. On peut aujourd'hui installer un système Linux avec de bons paquets bien signés et avoir au final un OS bourré de trous de sécurité. La sécurité c'est certes des binaires conformes mais c'est aussi la configuration qui va avec...
En plus, TCPA passe élégamment sous silence tous les langages de script. Il est trivial d'écrire un virus en VBScript, et pourtant l'interpréteur VBScript sera vraisemblablement signé correctement d'un point de vue TCPA vu qu'il est produit et édité par Microsoft. Que se passe-t-il alors? L'interpréteur vérifie toujours la signature d'un script avant de l'éxécuter? Comment les éditeurs de pages webs font-ils pour certifier toutes leurs pages? Qui se porte garant de la sécurité des scripts embarqués dans les courriers électroniques - et qui font quand même pas mal de dégâts aujourd'hui?
TCPA n'apporte en réalité aucune forme de sécurité valable pour l'utilisateur, tout au plus elle renforce le contrôle des éditeurs de logiciel sur l'utilisation de leur produit par les consommateurs, et accessoirement elle discrédite tous les programmes libres en les qualifiant arbitrairement de "non sécurisés".
Dernier point, il suffit de lire une licence Microsoft aujourd'hui pour voir que les éditeurs de logiciel ne se mouillent pas beaucoup question sécurité. Je ne serais pas étonné que les 1ers logiciels TCPA qui arriveront viennent avec des licenses similaires, où l'éditeur du soft se dégage de toute responsabilité. Donc concrêtement, point de vue sécurité vis-à-vis de l'éditeur ça sera comme aujourd'hui: confiance aveugle et aucune garantie légale en cas de disfonctionnement.
[^] # Re: Premier BIOS TCPA/Palladium
Posté par ufoot . En réponse à la dépêche Premier BIOS TCPA/Palladium. Évalué à 5.
???
Pas compris... En quoi TCPA garantit-il qu'il n'y a pas de buffer overflow? C'est le revendeur du programme qui l'affirme mais il est logé à la même enseigne que le revendeur Debian: il a produit un code et il doit vérifier que celui-ci ne comporte pas de bug ou de faille de sécurité. A ma connaissance, il n'existe pas aujourd'hui d'outils magique qui détecte automatiquement tous les buffers overflows et toutes les failles de sécurité. Les outils tels que purify sont encore bien imparfaits, et ne permettent que l'accélération de la recherche de bug, mais en aucun ils ne permettent une éradication systématique des fautes de programmation. Donc signature TCPA ou sceau MD5 c'est pareil: ça te dit que le programme que tu as est le même que celui que le programmeur voulait distribuer, et que tous les bugs que le programmeur a réussi à trouver ont été corrigés.
La signature TCPA n'apporte pas plus que la signature MD5 d'un paquet Debian du point de vue de l'utilisateur. Par contre vis-à-vis du revendeur du programme la différence est notoire car dans le 1er cas les éditeurs peuvent décider que si tu utilise un programme sans avoir la bonne signature alors le programme fonctionne en mode dégradé, voire pas du tout.
A part ça la signature des paquets n'est absolument pas une garantie de sécurité du système. On peut aujourd'hui installer un système Linux avec de bons paquets bien signés et avoir au final un OS bourré de trous de sécurité. La sécurité c'est certes des binaires conformes mais c'est aussi la configuration qui va avec...
En plus, TCPA passe élégamment sous silence tous les langages de script. Il est trivial d'écrire un virus en VBScript, et pourtant l'interpréteur VBScript sera vraisemblablement signé correctement d'un point de vue TCPA vu qu'il est produit et édité par Microsoft. Que se passe-t-il alors? L'interpréteur vérifie toujours la signature d'un script avant de l'éxécuter? Comment les éditeurs de pages webs font-ils pour certifier toutes leurs pages? Qui se porte garant de la sécurité des scripts embarqués dans les courriers électroniques - et qui font quand même pas mal de dégâts aujourd'hui?
TCPA n'apporte en réalité aucune forme de sécurité valable pour l'utilisateur, tout au plus elle renforce le contrôle des éditeurs de logiciel sur l'utilisation de leur produit par les consommateurs, et accessoirement elle discrédite tous les programmes libres en les qualifiant arbitrairement de "non sécurisés".
Dernier point, il suffit de lire une licence Microsoft aujourd'hui pour voir que les éditeurs de logiciel ne se mouillent pas beaucoup question sécurité. Je ne serais pas étonné que les 1ers logiciels TCPA qui arriveront viennent avec des licenses similaires, où l'éditeur du soft se dégage de toute responsabilité. Donc concrêtement, point de vue sécurité vis-à-vis de l'éditeur ça sera comme aujourd'hui: confiance aveugle et aucune garantie légale en cas de disfonctionnement.