Le parametre de memset a zero n'a aucun sens, il est sense etre positif --> flag
Que la variable soit connue a l'execution n'est pas forcement un probleme parce que certains de nos outils d'analyse evaluent les arbres et leurs contraintes et sont capables de voir quelles valeurs peuvent atterire dans une variable (pas tout le temps non plus et ils peuvent evidemment pas evaluer toutes les branches a toutes les profondeurs, on n'a pas encore trouve le graal), ces solveurs permettent par exemple de trouver si ton code accede a un buffer hors de sa taille, meme avec index variable.
Dans tous les cas cela montre qu’il ne faut pas trop se reposer sur ce genre d’outils. Ne serait-ce parce qu’il se peut que « l’erreur bête » donne quelque chose de valide à travers l’analyseur, la compilation et les tests. En cas de doute, la consultation de la documentation est primordiale. Alors les pages de man sont peut-être préhistoriques, mais c’est typiquement le genre de cas où leur légèreté et leur rapidité leur permettent d’être efficaces.
Ces outils ne doivent evidemment pas etre le debut et la fin, mais ils sont d'une utilite vraiment enorme, la difference en qualite de code avant qu'on les ait adopte et apres est tout simplement incroyable.
Ben si on devait tout refaire de 0 y compris en changeant l'education des gens, il y a plein de trucs qui se feraient differemment evidemment, mais faut vivre avec l'existant, avec les outils existants, avec ce que les gens connaissent et en sachant que faire adopter une nouveau language n'est pas chose facile.
T'es pourtant sur ce site depuis assez longtemps pour savoir que chez MS on ne reflechit pas, tout ce qui nous arrive n'est du qu'a la chance, la corruption et la stupidite de nos clients c'est bien connu.
A mon avis l'analyse sans annotation n'en vaut pas la peine. Elle a tellement de faux-positifs que le developpeur va vite en avoir marre et elle cause une explosion enorme des arbres d'evaluations qui rend l'analyse bcp moins efficace.
Par contre utiliser gcc pour le parsing a absolument tout son sens.
Simplement parce qu'il y a des annotations ne signifie pas que c'est pas "a vue d'oeil"
Jettes un oeil au kernel, combien de fonctions sont annotees ? --> Impossible d'analyser correctement, meme si t'as un bon outil
Regarde Sparse (http://linux.die.net/man/1/sparse), ou est le solveur de contraintes ? Il n'y en a pas, il est incapable de te dire par exemple qu'une boucle int b=4; while(b<5) ne s'arretera jamais car il ne peut pas comprendre l'execution du code et voir qu'aucun chemin ne permet de sortir.
Tu peux en decouvrire plus sur Coccinelle ici : http://coccinelle.lip6.fr/papers/fosdem10.pdf et tu decouvriras que c'est idem, c'est des patterns et autres, il n'y a aucune comprehension reelle du code, des appels de fonction, etc... et le nombre de faux-positifs peut etre sacrement eleve a cause de cela.
Aucun de ces softs n'est capable de vraiment savoir ce qui est attendu du code, parce que le code du kernel (et de tous les autres projets des distribs quasiment) n'est pas annote.
Rien ne permet de dire que le parametre length de blob(void* buffer, int length) est sense etre la longueur du buffer par exemple, ce qui empeche l'analyse statique d'etre efficace. Tu regardes le code de Windows par contre, il est quasi-entierement (voire entierement maintenant) annote du kernel jusqu'au demineur, ce qui permet aux softs genre PREfix et PREfast de verifier que le buffer qui a ete passe a la fonction dans la plupart des 32 chemins de code possible (il peut evidemment pas verifier tous les cas possibles et imaginables) a une taille au moins aussi grande que la valeur de la variable length, et que la fonction elle meme ne s'amuse pas a acceder au buffer plus loin que la valeur de la variable length.
La plupart de ces softs pour le kernel se contentent de faire de l'analyse "a vue d'oeil", il ne s'agit pas de vrais processeurs et analyseurs C avec un solveur derriere pour trouver les contraintes sur les variables, ils se contentent de voir que le code repond a certaines criteres basiques genre ne pas avoir un "if (a=x)" qui sont facilement detectables.
Bref, deux mondes totalement differents, un monde largement plus avance que l'autre.
Faut les comprendre, sous Linux c'est prehistorique et ils n'ont rien du genre de http://msdn.microsoft.com/en-us/windows/hardware/gg487345 pour eviter ces erreurs betes, alors que sous Windows tout le code est verifie avec ce genre d'outils constamment ce qui evite ces problemes.
Le code d'une partie de Windows 2000 dispo sur les torrents est la pour prouver de maniere irrefutable que c'est faux, il y a des conventions de codage.
Tu me fais rire, ils paient justement des gens pour faire ce boulot, tu voudrais qu'ils fassent quoi d'autre ?
Ils auraient attendu de nettoyer le code avant de l'ouvrir, vous vous seriez plaint qu'ils trainent des pieds pour ouvrir le code, etc...
Quand a la qualite des logiciels, le fait que l'enorme majorite des correctifs aient ete un changement entre le style interne a MS et celui de Linux montre plutot que la qualite est bonne, il y a eu au final peu de vrai bugs.
Si tu suivais le lien qu'il donne dans son article tu verrais que la majorite des trucs sont dus au style : ils codaient avec le style Windows (nommage des typdefs, etc...) et ont des lors du passer gentiment au style Linux, rien a voir avec une qualite de code mauvaise.
Ensuite il y avait des bugs dans leur code et des check-ins supplementaires pour les resoudre ? Grande nouvelle, c'est la meme chose dans le code du kernel qui voit des bugs corriges tout le temps.
Il y a plein de choses sur ce DVD: des symboles de debuggage par exemple, de la doc dans plusieurs langues, du code source, le platform SDK qui comprends les headers et les .lib pour l'OS, etc... l'IDE et le compilo ne sont qu'une petite partie du DVD.
•tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.
Et la taille de buffer pour strncpy tu l'oublies ? C'est un entier, comment tu le calcules sans te prendre les pieds dans le tapis ? Tu crois que ca sera toujours une valeur statique toute simple ?
On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.
Vraiment ? L'exemple que je t'ai donne est exactement la meme chose : se louper dans le calcul d'un des parametres, exactement comme dans ta phrase savoir passer les bons params a strncpy
une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.
Il y a plein d'implementations differentes oui tout a fait, c'est une des nombreuses raisons qui font que tu ne comprends toujours pas qu'eviter des BOFs est complique, parce qu'il y a 10'000 cas differents a gerer.
Si ton propos est de dire "appeler strcpy est simple dans 3 cas" super, mais ca on s'en fout pas mal, il reste 9997 cas a gerer.
•La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.
Moi je regarde les distribs dispo au grand public, et force est de constater qu'en tant que developpeur, tu n'as qu'un choix: eviter les BOFs dans ton code parce que les protections du systeme et du compilateur ne sont pas suffisantes pour te proteger.
Je regarde le type de projet :
- Base de donnees haute performance & disponibilite (Oracle)
- OS grand public stable et performant (Mac OS X, Windows, ...)
- Soft serveur performant & stable (Oracle encore, SQL Server, platformes Google, etc...)
Tout ca c'est des projets gros et extremement complexes, sans rapport avec l'enorme majorite des projets software. Evidemment tu vas avoir des petites boites specialisees dans les softs pour Airbus avec des requirements de qualite incroyables, mais compare a l'enorme majorite des boites de soft c'est clair et net. C'est d'ailleurs flagrant lors de nos rachats de societes, le code qu'on trouve est souvent de sacrement pietre qualite.
Meme pas malheureusement, a moins d'etre chef de projet ou bosser dans une banques les salaires de dev en Suisse volent pas super haut. C'est pas la pauvrete non plus, mais c'est sans rapport avec les USA.
Je doute tres tres fort que FB ait fait cela, ils se mettraient sour le risque d'un sacres proces aux USA vu que c'est la ou se trouvent les donnees et qu'il n'y avait aucun risque securitaire vis-a-vis des USA (ou meme d'Israel)
La question etait : "c est trop dur en C/C++ de borner un char *"
Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.
Je me suis contente de te parler de la realite, dans le monde reel, ou les BOFs sont legion, et qui prouve que non c'est pas simple.
Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?
J'en viens au kernel ? Quel rapport ? Le kernel est un bout de code en C/C++ comme un autre, si tu veux je te sors un BOF trouve la semaine passee dans un soft user-mode, il y en a a la pelle.
Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.
Et moi je te parles exactement de la meme chose mais tu ne le comprends pas, une appli qui lit un buffer sur plusieurs sockets a la fois car plusieurs connections en meme temps et qui a une race condition causant un BOF c'est quoi d'apres toi ?
Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.
La stack non-executable c'est un gag a passer, je t'invites a aller chercher ce qu'est le return-oriented programming par exemple.
Le jour ou Linux arrivera a notre cheville a se sujet on en reparlera, d'ici la je me contenterai de rire de ton post qui prouve que tu ne connais absolument rien au sujet.
Si tu installes absolument tout ca va certainement prendre bcp de place mais je connais peu de gens qui ont besoin des outils de dev pour embedded, pour VB, pour C#, pour C++, pour Office, pour SQL, etc... avec toutes les sous-options.
Surtout pas, les gens qui ont rachete Commodore USA sont des cons qui n'ont qu'un but : faire de l'argent en vendant des PCs sous un nom connu.
Leurs machines n'ont techniquement absolument aucun rapport avec le C64 ou l'Amiga, ils utilisent la forme et le nom purement comme outils mercantiles.
Pour retrouver un vrai Amiga il faut regarder du cote d'Hyperion (http://www.hyperion-entertainment.biz/ ) qui a les droits sur le developpement d'AmigaOS et sur le nom, qui a developpe AmigaOS4 et qui bosse sur la prochaine version.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -3.
Pas besoin de details, t'es un gars intelligent et je suis sur que tu as compris.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 2.
Le parametre de memset a zero n'a aucun sens, il est sense etre positif --> flag
Que la variable soit connue a l'execution n'est pas forcement un probleme parce que certains de nos outils d'analyse evaluent les arbres et leurs contraintes et sont capables de voir quelles valeurs peuvent atterire dans une variable (pas tout le temps non plus et ils peuvent evidemment pas evaluer toutes les branches a toutes les profondeurs, on n'a pas encore trouve le graal), ces solveurs permettent par exemple de trouver si ton code accede a un buffer hors de sa taille, meme avec index variable.
Dans tous les cas cela montre qu’il ne faut pas trop se reposer sur ce genre d’outils. Ne serait-ce parce qu’il se peut que « l’erreur bête » donne quelque chose de valide à travers l’analyseur, la compilation et les tests. En cas de doute, la consultation de la documentation est primordiale. Alors les pages de man sont peut-être préhistoriques, mais c’est typiquement le genre de cas où leur légèreté et leur rapidité leur permettent d’être efficaces.
Ces outils ne doivent evidemment pas etre le debut et la fin, mais ils sont d'une utilite vraiment enorme, la difference en qualite de code avant qu'on les ait adopte et apres est tout simplement incroyable.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 3.
Ben si on devait tout refaire de 0 y compris en changeant l'education des gens, il y a plein de trucs qui se feraient differemment evidemment, mais faut vivre avec l'existant, avec les outils existants, avec ce que les gens connaissent et en sachant que faire adopter une nouveau language n'est pas chose facile.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 0.
T'es pourtant sur ce site depuis assez longtemps pour savoir que chez MS on ne reflechit pas, tout ce qui nous arrive n'est du qu'a la chance, la corruption et la stupidite de nos clients c'est bien connu.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 0.
A mon avis l'analyse sans annotation n'en vaut pas la peine. Elle a tellement de faux-positifs que le developpeur va vite en avoir marre et elle cause une explosion enorme des arbres d'evaluations qui rend l'analyse bcp moins efficace.
Par contre utiliser gcc pour le parsing a absolument tout son sens.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -2.
Profite parce que le robinet va bientot se fermer
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 7.
Simplement parce qu'il y a des annotations ne signifie pas que c'est pas "a vue d'oeil"
Jettes un oeil au kernel, combien de fonctions sont annotees ? --> Impossible d'analyser correctement, meme si t'as un bon outil
Regarde Sparse (http://linux.die.net/man/1/sparse), ou est le solveur de contraintes ? Il n'y en a pas, il est incapable de te dire par exemple qu'une boucle int b=4; while(b<5) ne s'arretera jamais car il ne peut pas comprendre l'execution du code et voir qu'aucun chemin ne permet de sortir.
Tu peux en decouvrire plus sur Coccinelle ici : http://coccinelle.lip6.fr/papers/fosdem10.pdf et tu decouvriras que c'est idem, c'est des patterns et autres, il n'y a aucune comprehension reelle du code, des appels de fonction, etc... et le nombre de faux-positifs peut etre sacrement eleve a cause de cela.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 1.
"Lorsqu'un cheval boit il n'a plus soif". Loi de PbPg
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -1.
Aucun de ces softs n'est capable de vraiment savoir ce qui est attendu du code, parce que le code du kernel (et de tous les autres projets des distribs quasiment) n'est pas annote.
Rien ne permet de dire que le parametre length de blob(void* buffer, int length) est sense etre la longueur du buffer par exemple, ce qui empeche l'analyse statique d'etre efficace. Tu regardes le code de Windows par contre, il est quasi-entierement (voire entierement maintenant) annote du kernel jusqu'au demineur, ce qui permet aux softs genre PREfix et PREfast de verifier que le buffer qui a ete passe a la fonction dans la plupart des 32 chemins de code possible (il peut evidemment pas verifier tous les cas possibles et imaginables) a une taille au moins aussi grande que la valeur de la variable length, et que la fonction elle meme ne s'amuse pas a acceder au buffer plus loin que la valeur de la variable length.
La plupart de ces softs pour le kernel se contentent de faire de l'analyse "a vue d'oeil", il ne s'agit pas de vrais processeurs et analyseurs C avec un solveur derriere pour trouver les contraintes sur les variables, ils se contentent de voir que le code repond a certaines criteres basiques genre ne pas avoir un "if (a=x)" qui sont facilement detectables.
Bref, deux mondes totalement differents, un monde largement plus avance que l'autre.
[^] # Re: Réponse de masse
Posté par pasBill pasGates . En réponse au journal La solidité des mots de passe. Évalué à 5.
C'est peut-etre bon pour la securite, mais c'est pas bon pour la retention d'eau tout ce sel quand meme
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -10.
Dommage qu'aucun d'eux n'arrive a la cheville de PREfast et je ne parles meme pas de PREfix
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à -2.
Faut les comprendre, sous Linux c'est prehistorique et ils n'ont rien du genre de http://msdn.microsoft.com/en-us/windows/hardware/gg487345 pour eviter ces erreurs betes, alors que sous Windows tout le code est verifie avec ce genre d'outils constamment ce qui evite ces problemes.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 2.
Le code d'une partie de Windows 2000 dispo sur les torrents est la pour prouver de maniere irrefutable que c'est faux, il y a des conventions de codage.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 2.
Tu me fais rire, ils paient justement des gens pour faire ce boulot, tu voudrais qu'ils fassent quoi d'autre ?
Ils auraient attendu de nettoyer le code avant de l'ouvrir, vous vous seriez plaint qu'ils trainent des pieds pour ouvrir le code, etc...
Quand a la qualite des logiciels, le fait que l'enorme majorite des correctifs aient ete un changement entre le style interne a MS et celui de Linux montre plutot que la qualite est bonne, il y a eu au final peu de vrai bugs.
[^] # Re: et les implications juridique ?
Posté par pasBill pasGates . En réponse au journal Microsoft est dans le top 5 des contributeurs de linux 3.0. Évalué à 3.
Si tu suivais le lien qu'il donne dans son article tu verrais que la majorite des trucs sont dus au style : ils codaient avec le style Windows (nommage des typdefs, etc...) et ont des lors du passer gentiment au style Linux, rien a voir avec une qualite de code mauvaise.
Ensuite il y avait des bugs dans leur code et des check-ins supplementaires pour les resoudre ? Grande nouvelle, c'est la meme chose dans le code du kernel qui voit des bugs corriges tout le temps.
[^] # Re: Chacun son style
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Il y a plein de choses sur ce DVD: des symboles de debuggage par exemple, de la doc dans plusieurs langues, du code source, le platform SDK qui comprends les headers et les .lib pour l'OS, etc... l'IDE et le compilo ne sont qu'une petite partie du DVD.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
•tu n a pas relu ce qui etait dit, l exemple etait un strncpy et prendre en compte le '\0' dans le calcul. Rien a voir avec deux threads qui vont corrompre un size_t qui va ensuite partir sur une mauvaise utilisation du char *.
Et la taille de buffer pour strncpy tu l'oublies ? C'est un entier, comment tu le calcules sans te prendre les pieds dans le tapis ? Tu crois que ca sera toujours une valeur statique toute simple ?
On parlai de savoir utiliser strncpy sans faire de gaffe, tu es tout de suite parti totalement autre chose, qui sont des problemes en AMONT. Ne pas savoir coder un thread (ou une faute d etourderie, fatigue) et donc provoquer une corrumption memoire, ca n a rien a voir avec le fait de savoir dimensionner un char * et savoir passer les bons params a strncpy ou controler si une chaine passee a snprintf ne contiendrai pas des caracteres qui vont provoquer un seg.
Vraiment ? L'exemple que je t'ai donne est exactement la meme chose : se louper dans le calcul d'un des parametres, exactement comme dans ta phrase savoir passer les bons params a strncpy
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
une appli qui lit un buffer sur plusieurs sockets a la fois" Le probleme est la. tu as plusieurs sockets, mais un seul buffer pour stocker tout le monde a la fois ? on peux partir loin dans les implementations. On peux meme parler des forks et leurs limites.
Il y a plein d'implementations differentes oui tout a fait, c'est une des nombreuses raisons qui font que tu ne comprends toujours pas qu'eviter des BOFs est complique, parce qu'il y a 10'000 cas differents a gerer.
Si ton propos est de dire "appeler strcpy est simple dans 3 cas" super, mais ca on s'en fout pas mal, il reste 9997 cas a gerer.
•La stack non executable c est l un des mecanismes a mettre en oeuvre. Les ret2libc je connais bien ca aussi, c est la parade bien connue, mais plus difficile a maitriser car ils faut savoir pointer sur system(). On peux aussi complexifier le ret2libc via l ASLR, et surtout l ASLR sur un systeme 64bits, ou via noexec. On peux aussi utiliser certaines options de gcc comme -fstack-protection, le RELRO, et toutes ces joyeusetees. Il existe plusieurs projets tres sympa comme hardened gentoo/debian. Mais si on ne donne plus de contextes aux dialogues, on est pas pres de s arreter.
Moi je regarde les distribs dispo au grand public, et force est de constater qu'en tant que developpeur, tu n'as qu'un choix: eviter les BOFs dans ton code parce que les protections du systeme et du compilateur ne sont pas suffisantes pour te proteger.
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -2.
Tu m'as vu ou parler de taille d'entreprise ?
Je regarde le type de projet :
- Base de donnees haute performance & disponibilite (Oracle)
- OS grand public stable et performant (Mac OS X, Windows, ...)
- Soft serveur performant & stable (Oracle encore, SQL Server, platformes Google, etc...)
Tout ca c'est des projets gros et extremement complexes, sans rapport avec l'enorme majorite des projets software. Evidemment tu vas avoir des petites boites specialisees dans les softs pour Airbus avec des requirements de qualite incroyables, mais compare a l'enorme majorite des boites de soft c'est clair et net. C'est d'ailleurs flagrant lors de nos rachats de societes, le code qu'on trouve est souvent de sacrement pietre qualite.
[^] # Re: Chacun son style
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -4.
Meme pas malheureusement, a moins d'etre chef de projet ou bosser dans une banques les salaires de dev en Suisse volent pas super haut. C'est pas la pauvrete non plus, mais c'est sans rapport avec les USA.
[^] # Re: pb vie privé facebook google+
Posté par pasBill pasGates . En réponse au journal Réflexions après quelques jours de test de Google+. Évalué à -3.
Je doute tres tres fort que FB ait fait cela, ils se mettraient sour le risque d'un sacres proces aux USA vu que c'est la ou se trouvent les donnees et qu'il n'y avait aucun risque securitaire vis-a-vis des USA (ou meme d'Israel)
[^] # Re: Dépassement de tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -3.
La question etait : "c est trop dur en C/C++ de borner un char *"
Pour prouver que c est vrai, tu as derive sur "j ecrit mal mes threads en posant mal des mutex, pour corrompre mes variables" ce qui est un probleme d ecriture de threads.
Je me suis contente de te parler de la realite, dans le monde reel, ou les BOFs sont legion, et qui prouve que non c'est pas simple.
Maintenant, tu en es a venir au sein meme du kernel pour prouver le contraire. En quoi l ecriture d une application JAVA va changer le fonctionnement du KERNEL ?
J'en viens au kernel ? Quel rapport ? Le kernel est un bout de code en C/C++ comme un autre, si tu veux je te sors un BOF trouve la semaine passee dans un soft user-mode, il y en a a la pelle.
Moi je repondai aux BOFs quand il s agit de lire via son appli ce qui vient d une source externe, tu me parle de race condition au en interne d une appli, puis du kernel.
Et moi je te parles exactement de la meme chose mais tu ne le comprends pas, une appli qui lit un buffer sur plusieurs sockets a la fois car plusieurs connections en meme temps et qui a une race condition causant un BOF c'est quoi d'apres toi ?
Le bypass de grsec est tres sympa, je ne me rappelle pas l avoir vu, il faudrait que je check mes activitees pour cela. Mais je le repete, on est encore sorti du cas qui etait discute au debut, on est pas en train de faire un BOF sur un demon qui ecoute sur la socket, on a un programme qui s execute deja sur le systeme, donc on a deja bypass la stack qui n est pas executable, ce qui est bloque par GRSEC.
La stack non-executable c'est un gag a passer, je t'invites a aller chercher ce qu'est le return-oriented programming par exemple.
[^] # Re:Dépassementde tampon
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -9.
Le jour ou Linux arrivera a notre cheville a se sujet on en reparlera, d'ici la je me contenterai de rire de ton post qui prouve que tu ne connais absolument rien au sujet.
[^] # Re: Chacun son style
Posté par pasBill pasGates . En réponse à la dépêche Naissance d'un géant : Java. Évalué à -1.
Si tu installes absolument tout ca va certainement prendre bcp de place mais je connais peu de gens qui ont besoin des outils de dev pour embedded, pour VB, pour C#, pour C++, pour Office, pour SQL, etc... avec toutes les sous-options.
[^] # Re: support d'Amiga envers Aros
Posté par pasBill pasGates . En réponse au journal Nouvelles d'AROS - Amiga Research Operating System. Évalué à 2.
Surtout pas, les gens qui ont rachete Commodore USA sont des cons qui n'ont qu'un but : faire de l'argent en vendant des PCs sous un nom connu.
Leurs machines n'ont techniquement absolument aucun rapport avec le C64 ou l'Amiga, ils utilisent la forme et le nom purement comme outils mercantiles.
Pour retrouver un vrai Amiga il faut regarder du cote d'Hyperion (http://www.hyperion-entertainment.biz/ ) qui a les droits sur le developpement d'AmigaOS et sur le nom, qui a developpe AmigaOS4 et qui bosse sur la prochaine version.