"On ne peut pas faire confiance en AES car il a ete juge comme le
remplacement de DES par le gouvernement americain?" Sous-entendu, ils
savent casser une encryption AES assez rapidement.
Que repondre si la meme personne dit:
"Blowfish est surement meilleur en terme de confiance {par rapport a
AES} car il est dans OpenBSD depuis quelques annees" et que cette meme
personne jure ses Dieux paranoiaques que Blowfish est le seul capable
d'offrir la confidentialite suffisante.
Cela, ce n'est pas de moi mais d'AMcD je pense. Essayez de citer correctement, cela aidera le suivi.
Heu, moi, je n'en pense pas moins et l'ai d'ailleurs déjà formulé autrement sur d'autres NGs. Mais cette forme là doit plutôt être de Roland Garcia...
Je ne crois pas être intervenu dans ce fil mais comme on m'y invite....
Faisons court, sachant que les failles sont inéluctables autant ne pas prendre des risques inconsidérés, en tout pas plus que ce qu'il est possible de maitriser correctement. Une conception sans risque sera toujours très supérieure à un programme acrobatique qu'il ne sera peut-être pas possible de maitriser.
Il y a des exemples désespérés, comme IE/OE, alors que des équivalents n'ont strictement aucun problème, ceci n'a rien à voir avec la compétence des programmeurs.
PS: Je ne suis qu'un touriste informaticien issu du transistor durci (aux radiations)...
Roland Garcia
Pierre Vandevenne wrote:
Cela, ce n'est pas de moi mais d'AMcD je pense. Essayez de citer
correctement, cela aidera le suivi.
Heu, moi, je n'en pense pas moins et l'ai d'ailleurs déjà formulé autrement
sur d'autres NGs. Mais cette forme là doit plutôt être de Roland Garcia...
Je ne crois pas être intervenu dans ce fil mais comme on m'y invite....
Faisons court, sachant que les failles sont inéluctables autant ne pas
prendre des risques inconsidérés, en tout pas plus que ce qu'il est
possible de maitriser correctement. Une conception sans risque sera
toujours très supérieure à un programme acrobatique qu'il ne sera
peut-être pas possible de maitriser.
Il y a des exemples désespérés, comme IE/OE, alors que des équivalents
n'ont strictement aucun problème, ceci n'a rien à voir avec la
compétence des programmeurs.
PS: Je ne suis qu'un touriste informaticien issu du transistor durci
(aux radiations)...
Cela, ce n'est pas de moi mais d'AMcD je pense. Essayez de citer correctement, cela aidera le suivi.
Heu, moi, je n'en pense pas moins et l'ai d'ailleurs déjà formulé autrement sur d'autres NGs. Mais cette forme là doit plutôt être de Roland Garcia...
Je ne crois pas être intervenu dans ce fil mais comme on m'y invite....
Faisons court, sachant que les failles sont inéluctables autant ne pas prendre des risques inconsidérés, en tout pas plus que ce qu'il est possible de maitriser correctement. Une conception sans risque sera toujours très supérieure à un programme acrobatique qu'il ne sera peut-être pas possible de maitriser.
Il y a des exemples désespérés, comme IE/OE, alors que des équivalents n'ont strictement aucun problème, ceci n'a rien à voir avec la compétence des programmeurs.
PS: Je ne suis qu'un touriste informaticien issu du transistor durci (aux radiations)...
Roland Garcia
Pierre Vandevenne
Jean-Marc Desperrier wrote in news:bobl2t$2e9$1 @reader1.imaginet.fr:
Et puis pour les performances ... Java est aussi lent qu'un language de script,
zut alors, j'allais proposer d'émuler un DES cracker en Java. Cela ne fonctionnera donc pas bien? Un accélérateur de CDP peut-être?
mais doit être compilé. Je pense qu'à terme PHP vaincra.
J'ai bien lancé la flamewar ?
PHP? PHP, c'est bon pour qui ne comprend pas le Perl! ;-)
Allons-y!
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in news:bobl2t$2e9$1
@reader1.imaginet.fr:
Et puis pour les performances ... Java est aussi lent qu'un language de
script,
zut alors, j'allais proposer d'émuler un DES cracker en Java. Cela ne
fonctionnera donc pas bien? Un accélérateur de CDP peut-être?
mais doit être compilé. Je pense qu'à terme PHP vaincra.
J'ai bien lancé la flamewar ?
PHP? PHP, c'est bon pour qui ne comprend pas le Perl! ;-)
Jean-Marc Desperrier wrote in news:bobl2t$2e9$1 @reader1.imaginet.fr:
Et puis pour les performances ... Java est aussi lent qu'un language de script,
zut alors, j'allais proposer d'émuler un DES cracker en Java. Cela ne fonctionnera donc pas bien? Un accélérateur de CDP peut-être?
mais doit être compilé. Je pense qu'à terme PHP vaincra.
J'ai bien lancé la flamewar ?
PHP? PHP, c'est bon pour qui ne comprend pas le Perl! ;-)
Allons-y!
Johann Dantant
"Thomas Pornin" a écrit dans le message de news:bobgvj$1ls2$
Il arrive que des gens me posent benoîtement la question suivante : "mon petit frère/cousin/collègue/camarade de beuverie/autre voudrait apprendre à programmer, il doit commencer par quel langage ?"
Si je ne suis pas seul à ce moment, la question dégénère toujours en une flamewar monumentale ; mais sinon, ma réponse est en général : "le transistor, puis l'assembleur". C'est la méthode la plus rude pour commencer, mais c'est celle qui donne le plus de maîtrise après. On comprend tout au C quand on sait ce que le compilateur fait du code source et ce qu'il produit. On domine pleinement le Java quand on sait comment on ferait pour implémenter une JVM.
(En tous cas, cette réponse m'assure en général une originalité de bon aloi au milieu de la flamewar que j'évoquais plus haut. Vanter C, Java, CaML, Perl ou Python, c'est très banal. Mais le transistor, ça a du cachet.)
[...]
Qu'il est bon de vous lire... Généralement, à chaque nouveau stagiaire qui découvre le C après avoir soit-disant appris le sabir officiel "C/C++/Java/au fond c'est tout pareil" auprès de leurs doctes professeur, j'énonce les mêmes idées et les mêmes encouragement à chercher à comprendre ce qui se passe vraiment à l'intérieur de la machine, et pas seulement ce que ça déclenche (ou ne déclenche pas) sur l'écran... Les stagiaires ont au moins la gentillesse de ne pas me traîter de vieux croûlant (enfin, pas en face...), faut dire qu'à 29 ans ça me déprimerait... Par contre, lors des soutenances, les professeurs n'ont pas la même indulgence... Nombre d'entre eux s'indignent que j'ose proposer des sujets en C sur un micro embarqué, alors que Java fonctionne si bien sur toutes les plateformes... Nombre d'entre eux s'émeuvent de voir leurs chers étudiants en informatique faire figurer dans leurs rapports des tracés d'analyseur logique, voire des chronogrammes, vils outils de l'électronicien qui n'ont rien à faire dans leur cursus...
-- Johann Dantant
"Thomas Pornin" <pornin@nerim.net> a écrit dans le message de
news:bobgvj$1ls2$1@biggoron.nerim.net...
Il arrive que des gens me posent benoîtement la question suivante :
"mon petit frère/cousin/collègue/camarade de beuverie/autre voudrait
apprendre à programmer, il doit commencer par quel langage ?"
Si je ne suis pas seul à ce moment, la question dégénère toujours en
une flamewar monumentale ; mais sinon, ma réponse est en général : "le
transistor, puis l'assembleur". C'est la méthode la plus rude pour
commencer, mais c'est celle qui donne le plus de maîtrise après. On
comprend tout au C quand on sait ce que le compilateur fait du code
source et ce qu'il produit. On domine pleinement le Java quand on sait
comment on ferait pour implémenter une JVM.
(En tous cas, cette réponse m'assure en général une originalité de bon
aloi au milieu de la flamewar que j'évoquais plus haut. Vanter C, Java,
CaML, Perl ou Python, c'est très banal. Mais le transistor, ça a du
cachet.)
[...]
Qu'il est bon de vous lire... Généralement, à chaque nouveau stagiaire qui
découvre le C après avoir soit-disant appris le sabir officiel
"C/C++/Java/au fond c'est tout pareil" auprès de leurs doctes professeur,
j'énonce les mêmes idées et les mêmes encouragement à chercher à comprendre
ce qui se passe vraiment à l'intérieur de la machine, et pas seulement ce
que ça déclenche (ou ne déclenche pas) sur l'écran... Les stagiaires ont au
moins la gentillesse de ne pas me traîter de vieux croûlant (enfin, pas en
face...), faut dire qu'à 29 ans ça me déprimerait... Par contre, lors des
soutenances, les professeurs n'ont pas la même indulgence... Nombre d'entre
eux s'indignent que j'ose proposer des sujets en C sur un micro embarqué,
alors que Java fonctionne si bien sur toutes les plateformes... Nombre
d'entre eux s'émeuvent de voir leurs chers étudiants en informatique faire
figurer dans leurs rapports des tracés d'analyseur logique, voire des
chronogrammes, vils outils de l'électronicien qui n'ont rien à faire dans
leur cursus...
"Thomas Pornin" a écrit dans le message de news:bobgvj$1ls2$
Il arrive que des gens me posent benoîtement la question suivante : "mon petit frère/cousin/collègue/camarade de beuverie/autre voudrait apprendre à programmer, il doit commencer par quel langage ?"
Si je ne suis pas seul à ce moment, la question dégénère toujours en une flamewar monumentale ; mais sinon, ma réponse est en général : "le transistor, puis l'assembleur". C'est la méthode la plus rude pour commencer, mais c'est celle qui donne le plus de maîtrise après. On comprend tout au C quand on sait ce que le compilateur fait du code source et ce qu'il produit. On domine pleinement le Java quand on sait comment on ferait pour implémenter une JVM.
(En tous cas, cette réponse m'assure en général une originalité de bon aloi au milieu de la flamewar que j'évoquais plus haut. Vanter C, Java, CaML, Perl ou Python, c'est très banal. Mais le transistor, ça a du cachet.)
[...]
Qu'il est bon de vous lire... Généralement, à chaque nouveau stagiaire qui découvre le C après avoir soit-disant appris le sabir officiel "C/C++/Java/au fond c'est tout pareil" auprès de leurs doctes professeur, j'énonce les mêmes idées et les mêmes encouragement à chercher à comprendre ce qui se passe vraiment à l'intérieur de la machine, et pas seulement ce que ça déclenche (ou ne déclenche pas) sur l'écran... Les stagiaires ont au moins la gentillesse de ne pas me traîter de vieux croûlant (enfin, pas en face...), faut dire qu'à 29 ans ça me déprimerait... Par contre, lors des soutenances, les professeurs n'ont pas la même indulgence... Nombre d'entre eux s'indignent que j'ose proposer des sujets en C sur un micro embarqué, alors que Java fonctionne si bien sur toutes les plateformes... Nombre d'entre eux s'émeuvent de voir leurs chers étudiants en informatique faire figurer dans leurs rapports des tracés d'analyseur logique, voire des chronogrammes, vils outils de l'électronicien qui n'ont rien à faire dans leur cursus...
-- Johann Dantant
Jean-Marc Desperrier
Roland Garcia wrote:
Faisons court, sachant que les failles sont inéluctables autant ne pas prendre des risques inconsidérés, en tout pas plus que ce qu'il est possible de maitriser correctement.
En fait, la meilleure solution est d'intervenir au niveau de l'OS pour renforcer les mécanismes de sécurité, en utilisant quelquechose de plus évolué que ceux traditionnels des Unix, qui est une conception qui date quand du tout début des années 70 et commence à vieillir un peu.
L'une des ces solution est l'architecture flask, inspirée des études sur les micro-noyaux, qui essentiellement sépare le noyaux en deux élement un gestionnaire d'objet, et un server de sécurité. Le gestionnaire d'objet consulte le server de sécurité avant de créer chaque objet et une politique de sécurité avec une granularitée très détaillée peut être réalisée pour indiquer qui a le droit de créer quoi.
Flask peut être appliquée à pas mal d'OS, et il existe une évolution de Linux, Security-Enhanced Linux, qui incorpore ce mécanisme, dévellopé en open source par de vrai spécialistes de la sécurité qui dispose d'une expérience et de moyens extrêmement important. L'URL est ici : http://www.nsa.gov/selinux/
Comment cela ! Ya quelquechose qui vous choque dans la première partie de cette URL ?
Roland Garcia wrote:
Faisons court, sachant que les failles sont inéluctables autant ne pas
prendre des risques inconsidérés, en tout pas plus que ce qu'il est
possible de maitriser correctement.
En fait, la meilleure solution est d'intervenir au niveau de l'OS pour
renforcer les mécanismes de sécurité, en utilisant quelquechose de plus
évolué que ceux traditionnels des Unix, qui est une conception qui date
quand du tout début des années 70 et commence à vieillir un peu.
L'une des ces solution est l'architecture flask, inspirée des études sur
les micro-noyaux, qui essentiellement sépare le noyaux en deux élement
un gestionnaire d'objet, et un server de sécurité. Le gestionnaire
d'objet consulte le server de sécurité avant de créer chaque objet et
une politique de sécurité avec une granularitée très détaillée peut être
réalisée pour indiquer qui a le droit de créer quoi.
Flask peut être appliquée à pas mal d'OS, et il existe une évolution de
Linux, Security-Enhanced Linux, qui incorpore ce mécanisme, dévellopé en
open source par de vrai spécialistes de la sécurité qui dispose d'une
expérience et de moyens extrêmement important.
L'URL est ici :
http://www.nsa.gov/selinux/
Comment cela ! Ya quelquechose qui vous choque dans la première partie
de cette URL ?
Faisons court, sachant que les failles sont inéluctables autant ne pas prendre des risques inconsidérés, en tout pas plus que ce qu'il est possible de maitriser correctement.
En fait, la meilleure solution est d'intervenir au niveau de l'OS pour renforcer les mécanismes de sécurité, en utilisant quelquechose de plus évolué que ceux traditionnels des Unix, qui est une conception qui date quand du tout début des années 70 et commence à vieillir un peu.
L'une des ces solution est l'architecture flask, inspirée des études sur les micro-noyaux, qui essentiellement sépare le noyaux en deux élement un gestionnaire d'objet, et un server de sécurité. Le gestionnaire d'objet consulte le server de sécurité avant de créer chaque objet et une politique de sécurité avec une granularitée très détaillée peut être réalisée pour indiquer qui a le droit de créer quoi.
Flask peut être appliquée à pas mal d'OS, et il existe une évolution de Linux, Security-Enhanced Linux, qui incorpore ce mécanisme, dévellopé en open source par de vrai spécialistes de la sécurité qui dispose d'une expérience et de moyens extrêmement important. L'URL est ici : http://www.nsa.gov/selinux/
Comment cela ! Ya quelquechose qui vous choque dans la première partie de cette URL ?
Erwann ABALEA
On 5 Nov 2003, Pierre Vandevenne wrote:
Jean-Marc Desperrier wrote in news:bobl2t$2e9$1 @reader1.imaginet.fr:
Et puis pour les performances ... Java est aussi lent qu'un language de script,
zut alors, j'allais proposer d'émuler un DES cracker en Java. Cela ne fonctionnera donc pas bien? Un accélérateur de CDP peut-être?
Ah, il y a de grandes chances que ça aille plus vite en Java qu'en VB... Attention, je n'ai pas dit que rien n'est plus lent que VB... Je ne fais que le penser... ;)
mais doit être compilé. Je pense qu'à terme PHP vaincra.
J'ai bien lancé la flamewar ?
PHP? PHP, c'est bon pour qui ne comprend pas le Perl! ;-)
Perl, c'est juste bon pour ceux qui ne savent pas écrire des scripts shell et qui ne comprennent pas awk, sed, cut, tr, col, ...
Allons-y!
Toi-même!
;)
Et je certifie que la signature ci-dessous a été tirée au hasard dans ma liste... Pour rester on-topic, on n'a pas toujours besoin d'un BBS, même un bon vieux rand() initialisé avec l'heure courante suffit... :)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Ta race, zorro de pute tu devrais plutot aller sucer des teubs chez les grecs au lieu d'écrire nawakos!! rajoute moi donc dans ton robot tueur. mouhaha, je te crache a la geule et ca te degouline jusqu'auxx baskets! -+- Nono in <http://neuneu.mine.nu> : Vingt ans de finesse -+-
On 5 Nov 2003, Pierre Vandevenne wrote:
Jean-Marc Desperrier <jmdesp@alussinan.org> wrote in news:bobl2t$2e9$1
@reader1.imaginet.fr:
Et puis pour les performances ... Java est aussi lent qu'un language de
script,
zut alors, j'allais proposer d'émuler un DES cracker en Java. Cela ne
fonctionnera donc pas bien? Un accélérateur de CDP peut-être?
Ah, il y a de grandes chances que ça aille plus vite en Java qu'en VB...
Attention, je n'ai pas dit que rien n'est plus lent que VB... Je ne fais
que le penser... ;)
mais doit être compilé. Je pense qu'à terme PHP vaincra.
J'ai bien lancé la flamewar ?
PHP? PHP, c'est bon pour qui ne comprend pas le Perl! ;-)
Perl, c'est juste bon pour ceux qui ne savent pas écrire des scripts shell
et qui ne comprennent pas awk, sed, cut, tr, col, ...
Allons-y!
Toi-même!
;)
Et je certifie que la signature ci-dessous a été tirée au hasard dans ma
liste... Pour rester on-topic, on n'a pas toujours besoin d'un BBS, même
un bon vieux rand() initialisé avec l'heure courante suffit... :)
--
Erwann ABALEA <erwann@abalea.com> - RSA PGP Key ID: 0x2D0EABD5
-----
Ta race, zorro de pute tu devrais plutot aller sucer des teubs chez les
grecs au lieu d'écrire nawakos!! rajoute moi donc dans ton robot tueur.
mouhaha, je te crache a la geule et ca te degouline jusqu'auxx baskets!
-+- Nono in <http://neuneu.mine.nu> : Vingt ans de finesse -+-
Jean-Marc Desperrier wrote in news:bobl2t$2e9$1 @reader1.imaginet.fr:
Et puis pour les performances ... Java est aussi lent qu'un language de script,
zut alors, j'allais proposer d'émuler un DES cracker en Java. Cela ne fonctionnera donc pas bien? Un accélérateur de CDP peut-être?
Ah, il y a de grandes chances que ça aille plus vite en Java qu'en VB... Attention, je n'ai pas dit que rien n'est plus lent que VB... Je ne fais que le penser... ;)
mais doit être compilé. Je pense qu'à terme PHP vaincra.
J'ai bien lancé la flamewar ?
PHP? PHP, c'est bon pour qui ne comprend pas le Perl! ;-)
Perl, c'est juste bon pour ceux qui ne savent pas écrire des scripts shell et qui ne comprennent pas awk, sed, cut, tr, col, ...
Allons-y!
Toi-même!
;)
Et je certifie que la signature ci-dessous a été tirée au hasard dans ma liste... Pour rester on-topic, on n'a pas toujours besoin d'un BBS, même un bon vieux rand() initialisé avec l'heure courante suffit... :)
-- Erwann ABALEA - RSA PGP Key ID: 0x2D0EABD5 ----- Ta race, zorro de pute tu devrais plutot aller sucer des teubs chez les grecs au lieu d'écrire nawakos!! rajoute moi donc dans ton robot tueur. mouhaha, je te crache a la geule et ca te degouline jusqu'auxx baskets! -+- Nono in <http://neuneu.mine.nu> : Vingt ans de finesse -+-
pas.de.spam
"AMcD" wrote in message news:<3fa9192f$0$243$...
Pierre Vandevenne wrote:
Si ce gars bosse sur des logiciels commerciaux, allez, compliquons un peu, devant fonctionner en réseau (ne parlons même pas de logiciels critiques ou sécuritaires), imagine la différence ! Il faut que le gars pense aux buffers overflows, aux strings overflows, aux integers overflows, aux stack overflows, aux détournement de privilège, aux injections de code, aux races conditions, aux... stop ! Si le chef de projet à du buget à faire rentrer, je doute que les programmeurs aient le temps de penser à ça, de mettre en oeuvre des tests élaborés, de la vérification de code, etc. Y sont-ils formés d'ailleurs ? Dans un univers ou le code doit toujours pêtre prêt pour avant-hier, est-ce vraiment la faute du programmeur si il y a des failles. Suivant le contexte, les programmeurs auront ou pas la possibilité et le temps de penser à tout ça. Suivant le contexte, des gens seront payés pour veiller à ça. Parce que on ne peux pas non plus demander au programmeur de en plus de son boulot se tenir au courant des dernières techniques d'attaques. Il le fait quand ? il dort plus, il mange plus ?
Il y a des méthodes qui améliorent la qualité du logiciel par exemple en écrivant les tests avant les algorithmes (méthode XP, outils *UNIT, etc), cela contribue a réduire les bugs, mais pas les failles dues aux buffers overflows et autres. Pour les failles, quelles sont les parades : existe il des langages de programmation qui soient moins vulnérables aux failles type buffer overflow etc ? ou des inspecteurs de code ?
"AMcD" <arnold.mcdonald@free.fr> wrote in message news:<3fa9192f$0$243$636a55ce@news.free.fr>...
Pierre Vandevenne wrote:
Si ce gars bosse sur des logiciels commerciaux, allez, compliquons un peu,
devant fonctionner en réseau (ne parlons même pas de logiciels critiques ou
sécuritaires), imagine la différence ! Il faut que le gars pense aux buffers
overflows, aux strings overflows, aux integers overflows, aux stack
overflows, aux détournement de privilège, aux injections de code, aux races
conditions, aux... stop ! Si le chef de projet à du buget à faire rentrer,
je doute que les programmeurs aient le temps de penser à ça, de mettre en
oeuvre des tests élaborés, de la vérification de code, etc. Y sont-ils
formés d'ailleurs ? Dans un univers ou le code doit toujours pêtre prêt pour
avant-hier, est-ce vraiment la faute du programmeur si il y a des failles.
Suivant le contexte, les programmeurs auront ou pas la possibilité et le
temps de penser à tout ça. Suivant le contexte, des gens seront payés pour
veiller à ça. Parce que on ne peux pas non plus demander au programmeur de
en plus de son boulot se tenir au courant des dernières techniques
d'attaques. Il le fait quand ? il dort plus, il mange plus ?
Il y a des méthodes qui améliorent la qualité du logiciel par exemple
en écrivant les tests avant les algorithmes (méthode XP, outils *UNIT,
etc), cela contribue a réduire les bugs, mais pas les failles dues aux
buffers overflows et autres.
Pour les failles, quelles sont les parades : existe il des langages de
programmation qui soient moins vulnérables aux failles type buffer
overflow etc ? ou des inspecteurs de code ?
Si ce gars bosse sur des logiciels commerciaux, allez, compliquons un peu, devant fonctionner en réseau (ne parlons même pas de logiciels critiques ou sécuritaires), imagine la différence ! Il faut que le gars pense aux buffers overflows, aux strings overflows, aux integers overflows, aux stack overflows, aux détournement de privilège, aux injections de code, aux races conditions, aux... stop ! Si le chef de projet à du buget à faire rentrer, je doute que les programmeurs aient le temps de penser à ça, de mettre en oeuvre des tests élaborés, de la vérification de code, etc. Y sont-ils formés d'ailleurs ? Dans un univers ou le code doit toujours pêtre prêt pour avant-hier, est-ce vraiment la faute du programmeur si il y a des failles. Suivant le contexte, les programmeurs auront ou pas la possibilité et le temps de penser à tout ça. Suivant le contexte, des gens seront payés pour veiller à ça. Parce que on ne peux pas non plus demander au programmeur de en plus de son boulot se tenir au courant des dernières techniques d'attaques. Il le fait quand ? il dort plus, il mange plus ?
Il y a des méthodes qui améliorent la qualité du logiciel par exemple en écrivant les tests avant les algorithmes (méthode XP, outils *UNIT, etc), cela contribue a réduire les bugs, mais pas les failles dues aux buffers overflows et autres. Pour les failles, quelles sont les parades : existe il des langages de programmation qui soient moins vulnérables aux failles type buffer overflow etc ? ou des inspecteurs de code ?
Pierre Vandevenne
Erwann ABALEA wrote in news::
Et je certifie que la signature ci-dessous a été tirée au hasard dans ma liste...
Je suis heureux qu'après toutes ces années tu sois enfin capable de verbaliser ce que tu penses réellement de moi ;-)
Erwann ABALEA <erwann@abalea.com> wrote in
news:Pine.LNX.4.33.0311071543500.28761-100000@patchwork.seclogd.org:
Et je certifie que la signature ci-dessous a été tirée au hasard dans
ma liste...
Je suis heureux qu'après toutes ces années tu sois enfin capable de
verbaliser ce que tu penses réellement de moi ;-)
Et je certifie que la signature ci-dessous a été tirée au hasard dans ma liste...
Je suis heureux qu'après toutes ces années tu sois enfin capable de verbaliser ce que tu penses réellement de moi ;-)
Pierre Vandevenne
(olivier) wrote in news::
en écrivant les tests avant les algorithmes (méthode XP, outils *UNIT,
<snip>
Pour les failles, quelles sont les parades : existe il des langages de programmation qui soient moins vulnérables aux failles type buffer overflow etc ?
Voir le message de TP - oui, les langages de style Java offrent une meilleure protection native. Il y a aussi is SP - safe programming.
Par exemple "Secure Programming Cookbook for C and C++" ou encore "Writing Secure Code", Second Edition.
ou des inspecteurs de code ?
purify, pc lint ont développé des fonctionalités dans ce sens.
http://www.gimpel.com/html/mimicry.htm
Le projet public de loin le plus intéressant est celui ci
http://www.cs.wisc.edu/wisa/index.html
Je suis légèrement biaisé en leur faveur parce qu'ils utilisent notre soft, mais ce sont des gens qui allient la rigueur scientifique quelque peu convenue des doctorants typiques à une bonne compréhension des réalités de la dure vie de l'octet.
Les papiers et les présentations sont souvent excellentes.
Bon je vous laisse, je suis coincé entre le dernier Chomski et le Testaments des Siècles ;-)
pas.de.spam@wanadoo.fr (olivier) wrote in
news:f01030a9.0311071250.57ddf394@posting.google.com:
en écrivant les tests avant les algorithmes (méthode XP, outils *UNIT,
<snip>
Pour les failles, quelles sont les parades : existe il des langages de
programmation qui soient moins vulnérables aux failles type buffer
overflow etc ?
Voir le message de TP - oui, les langages de style Java offrent une
meilleure protection native. Il y a aussi is SP - safe programming.
Par exemple "Secure Programming Cookbook for C and C++" ou encore
"Writing Secure Code", Second Edition.
ou des inspecteurs de code ?
purify, pc lint ont développé des fonctionalités dans ce sens.
http://www.gimpel.com/html/mimicry.htm
Le projet public de loin le plus intéressant est celui ci
http://www.cs.wisc.edu/wisa/index.html
Je suis légèrement biaisé en leur faveur parce qu'ils utilisent notre
soft, mais ce sont des gens qui allient la rigueur scientifique quelque
peu convenue des doctorants typiques à une bonne compréhension des
réalités de la dure vie de l'octet.
Les papiers et les présentations sont souvent excellentes.
Bon je vous laisse, je suis coincé entre le dernier Chomski et le
Testaments des Siècles ;-)
en écrivant les tests avant les algorithmes (méthode XP, outils *UNIT,
<snip>
Pour les failles, quelles sont les parades : existe il des langages de programmation qui soient moins vulnérables aux failles type buffer overflow etc ?
Voir le message de TP - oui, les langages de style Java offrent une meilleure protection native. Il y a aussi is SP - safe programming.
Par exemple "Secure Programming Cookbook for C and C++" ou encore "Writing Secure Code", Second Edition.
ou des inspecteurs de code ?
purify, pc lint ont développé des fonctionalités dans ce sens.
http://www.gimpel.com/html/mimicry.htm
Le projet public de loin le plus intéressant est celui ci
http://www.cs.wisc.edu/wisa/index.html
Je suis légèrement biaisé en leur faveur parce qu'ils utilisent notre soft, mais ce sont des gens qui allient la rigueur scientifique quelque peu convenue des doctorants typiques à une bonne compréhension des réalités de la dure vie de l'octet.
Les papiers et les présentations sont souvent excellentes.
Bon je vous laisse, je suis coincé entre le dernier Chomski et le Testaments des Siècles ;-)
Michel Arboi
Pierre Vandevenne writes:
Voir le message de TP - oui, les langages de style Java offrent une meilleure protection native.
Ada, Pascal, etc., sont censés vérifier les indices de tableaux, donc être immunisés contre ces problèmes idiots. Il y a eu des patchs "bound checking" de GCC qui n'ont jamais été intégrés dans l'outil (pourquoi donc ?) gcc -fbounds-check ne marche que pour Java et F77 d'après la page d'info.
ou des inspecteurs de code ? purify, pc lint ont développé des fonctionalités dans ce sens.
http://www.gimpel.com/html/mimicry.htm Le projet public de loin le plus intéressant est celui ci http://www.cs.wisc.edu/wisa/index.html
De toute façon, l'inspection de code ne peut pas détecter tous les bugs de ce type ?!
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
Pierre Vandevenne <pierre@datarescue.be> writes:
Voir le message de TP - oui, les langages de style Java offrent une
meilleure protection native.
Ada, Pascal, etc., sont censés vérifier les indices de tableaux, donc
être immunisés contre ces problèmes idiots.
Il y a eu des patchs "bound checking" de GCC qui n'ont jamais été
intégrés dans l'outil (pourquoi donc ?)
gcc -fbounds-check ne marche que pour Java et F77 d'après la page d'info.
ou des inspecteurs de code ?
purify, pc lint ont développé des fonctionalités dans ce sens.
http://www.gimpel.com/html/mimicry.htm
Le projet public de loin le plus intéressant est celui ci
http://www.cs.wisc.edu/wisa/index.html
De toute façon, l'inspection de code ne peut pas détecter tous les
bugs de ce type ?!
--
arboi@alussinan.org http://arboi.da.ru
FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
Voir le message de TP - oui, les langages de style Java offrent une meilleure protection native.
Ada, Pascal, etc., sont censés vérifier les indices de tableaux, donc être immunisés contre ces problèmes idiots. Il y a eu des patchs "bound checking" de GCC qui n'ont jamais été intégrés dans l'outil (pourquoi donc ?) gcc -fbounds-check ne marche que pour Java et F77 d'après la page d'info.
ou des inspecteurs de code ? purify, pc lint ont développé des fonctionalités dans ce sens.
http://www.gimpel.com/html/mimicry.htm Le projet public de loin le plus intéressant est celui ci http://www.cs.wisc.edu/wisa/index.html
De toute façon, l'inspection de code ne peut pas détecter tous les bugs de ce type ?!
-- http://arboi.da.ru FAQNOPI de fr.comp.securite http://faqnopi.da.ru/
Pierre Vandevennne
Michel Arboi wrote in news::
De toute façon, l'inspection de code ne peut pas détecter tous les bugs de ce type ?!
Non, si tu as une solution à 10% pour les binaires, tu es un homme riche.
Michel Arboi <TMPloyhk70@passoire.afraid.org> wrote in
news:m3islvdopa.fsf@passoire.afraid.org:
De toute façon, l'inspection de code ne peut pas détecter tous les
bugs de ce type ?!
Non, si tu as une solution à 10% pour les binaires, tu es un homme riche.
