Ben je lis cette info regulierement, alors j'ai cherche 30 secondes, trouve un lien demontrant que des gens faisant des comptes assez serieux disent de meme, et voila, j'allais pas te faire une analyse profonde sur 20 pages quand meme :)
Pour ce qui est du "vrai cout de windows", ben tu trouveras plein de gens te disant que ce vrai cout, il est plus bas que le concurrent d'en face quand tu mesures la totalite…
Pour les serveurs web, si tu regardes le meme site reference dans ce journal, il montre Windows a 30% du marche des serveurs web public, eh oui, il n'y a pas que IIS comme serveur web sous Windows !
According to IDC, Windows Server accounted for 71 percent of all second quarter server shipments, with revenue of $5.9 billion representing 45.5 percent of worldwide revenue. The rest of the market is split among Linux, mainframes, Unix and others.
a) Tu as le contrat avec OHA ? Moi je l'ai pas et il n'est pas sur le site de l'OHA non plus
b) Tu en sais quoi que le contrat de MS n'etait pas le meme avec tous les OEMs ? Rien
c) Oui tout a fait, Acer peut utiliser Aliyun, tout comme Hitachi (je crois que c'etait eux) pouvait utiliser BeOS. Acer devra faire sans support, ce qui augmente leur couts, et Hitachi aurait du faire avec un Windows un peu plus cher, ce qui augmente leurs couts, quelle difference…
Amazon a simplement tire avantage du fait que Android est libre et cela marche pour eux car ils n'ont jamais eu l'intention d'avoir Android de Google, Google n'a aucun moyen de pression sur eux, contrairement a Acer.
Compares ca a MS qui ferait payer un OEM plus cher sa copie de Windows compare aux autres OEMs… Exactement ce qui est arrive et qui a value un sacre merdier a MS.
Enlever l'acces en avance et le support, ca revient exactement au meme que ce que MS avait fait. Le seul truc qui sauve Google pour l'instant est qu'ils ne sont pas un monopole.
Ma reponse est simple: Si cela avait ete MS, il se serait pris un proces pour abus de monopole.
Ici Google fait de meme avec un OS qui a 60% du marche…
Faire partie de "OHA" est essentiel pour tout constructeur de smartphone qui veut faire de l'Android. Les regles de l'OHA, j'en comprends une partie, mais je les trouves sacrement limite en ce qui concerne l'interdiction de vendre un fork "incompatible avec Android". Ils ne limitent pas les constructeurs a tous les autres OS, mais une partie specifique. Maintenant je comprendrais qu'ils disent "ne dites pas que ces OS sont compatible-Android", mais qu'ils interdisent l'utilisation de l'OS forke tout simplement c'est extreme de mon point de vue.
Pour le reste, Alibaba n'a aucune excuse en ce qui concerne les softs pirates, c'est inacceptable (et ca a toujours ete un des problemes d'Android, je ne comprends pas que Google ne fasse rien contre).
Peut-etre un petit peu oui, c'etait a un niveau technique tellement eleve que la plupart de la salle ne pouvait pas suivre car n'avait pas les connaissances necessaires.
"Acer will continue to communicate with Google and the company still wants to launch the new smartphone based on Alibaba software," an official at Acer, who declined to be named, said.
Ce n'est nullement de la haine. Mirosoft en lui-même m'indiffère
Vu ta propension a focaliser sur MS dans tes critiques sans faire le moindre effort pour relativiser ce qu'ils font, si c'est de la haine.
Jusque dans les milieux libristes, ils ont réussi à instiller une pensée lénifiante, masquant dans l'esprit des gens la réalité de leur entreprise. Quiconque y réfléchit posément ne peut que se rendre compte qu'ils demeurent, bien plus que nombre de leur concurrents (pomme notamment) l'un des principaux obstacles au libre, et partant une nuisance majeure pour l'économie mondiale.
Bonjour Mr Stallman, comment se porte votre religion aujourd'hui ?
Desole, mais tu ne fais que confirmer ce que je dis plus haut dans cette phrase : tu as un comportement aveugle et uniquement dicte par un dogme(le libre ou la mort).
Malheureusement, cette réalité tient à l'objet sociale de la compagnie. Objet qui ne souffre pas la moindre pondération morale, même de pur principe, comme pour google. Du coup, aucun espoir n'est permis en la matière. Et c'est bien dommage étant donné les trésors techniques qu'accumule microsot. Un pas d'humanité, si proche, si cours, si aisé, et qui pourtant ne sera jamais accompli, suffirait à les emmener du nadir au zénith.
Et tu continues en parlant de MS sans aucun principe moral, alors que parait-il Google oui. Sachant que tu n'as jamais mis les pieds dans aucune des 2 societes.
Que Google ne veuille pas faire le support du fork, je le comprends totalement. Qu'ils disent a Acer "abandonnez vos projets sinon on coupe notre support Android" par contre, pas trop.
Tu aurais presque raison, a part le fait qu'ici l'info vient directement d'officiels d'Alibaba ET Acer qui sont cites anonymement. C'est pas simplement Alibaba, concurrent de Google, ou des fanboys imaginant ce qu'ils veulent, et c'est toute la difference.
Pour les pressions, elles sont surement differentes vu la nature du produit oui, mais enlever le support a Acer revient effectivement a les forcer a forker et supporter un OS seuls, ce qui augmente enormement leurs couts et rend la vente de smartphones Android a prix concurrentiel impossible.
Entre d'une part une firme dont les contributions positives pour le progrès sont inexistantes ou du moins négligeables et largement ignorées, et d'autre part une compagnie encore présentement au sommet inégalé d'une activité qui a révolutionné le monde. Peut-être est-ce dû aux principes diamétralement opposés ? du « do no evil » au culte des méthodes commerciales, l'abîme est insondable
et
spécial dédicace à la B.&M. G. F. et, par exemple, à ses financement hasardeux d'essais cliniques chimiques in-vivo sur des populations en deshérence ; mais aussi aux multiples craques qu'engendre la concentration
Pour se rendre compte a quel point tu as une haine de tout ce qui touche de pres ou de loin a MS sans aucune echelle de valeur. Tes mots sont a une extreme tellement absurde qu'ils ne valent absolument rien.
Reviens nous voir une fois que tu auras compare de maniere posee les bienfaits et mefaits de MS/Google et la fondation Gates plutot que vociferer une haine aveugle.
1) Je te suggeres de rester poli, surtout que tu as faux sur toute la ligne, et on est plusieurs a te le dire.
2) Le code serialisant des objets, les conteneurs video, etc… ont tous ces problemes, je te suggeres d'aller regarder les patches pour failles de securite dans libjpeg / libpng etc… cf. http://blog.cr0.org/2009/05/write-once-own-everyone.html par exemple.
3) Il y en a , tu l'as montre toi meme : attendre est de la gestion d'erreur, tu verifies la valeur retournee et tu evites un crash. Quelqu'un d'autre t'as montre plus bas qu'Inkscape gerait cela aussi et plein d'autres softs font de meme
Maintenant regardes ce qu'il se passe dans le imalloc de init au cas ou un autre goret coderait comme toi : ça part en boucle infinie! Mais c'est pas génial ça!
Tu es un sacre clown quand meme, tu as vu ou que j'ecrirais un code qui part en boucle infinie ? Tu as deja vu mon code ?
La difference entre toi et moi c'est que moi mon code tourne sur un milliard de machines, y compris des serveurs surcharges, et la plupart du temps sans probleme. Toi tu es visiblement bon pour insulter les gens, et beaucoup moins pour comprendre comment programmer proprement.
De nouveau non tu ne comprends rien, le checksum ou le marqueur ne changent rien
A) Si je veux t'attaquer, je peux t'envoyer un fichier avec un mauvais champs longueur et une checksum correcte. Mais c'est de toute facon pas important parce que si le format du fichier ne comprend pas de checksum ou de marqueur, ben voila, tu ne peux pas en rajouter, tout simplement car le format n'en a pas et tu aurais des lors un fichier non conforme.
b) Ecraser le buffer n'est pas le probleme
[taille: 100'000][buffer compresse de 50'000 octets, qui disons va etre decompresse a 120'000 octets]
Rien ne t'empeche de traiter ca correctement, tu sais que tu as alloue 100'000 bytes, suffit de t'assurer que tu n'ecris pas plus de 100'000 bytes quand tu decompresses et retourner une erreur si il y a des donnees restantes.
[taille: 1'900'000'000][buffer compresse de 50'000 octets, qui disons va etre decompresse a 120'000 octets]
Ici, avant meme de commencer a decompresser, ton malloc a de tres grandes chances de retourner NULL sur x86 et tu vas exploser immediatement si tu ne verifies pas la valeur de retour.
A) Mais de nouveau, si le parametre 'longueur' est corrompu, comment tu le sais quand tu lis ton fichier ?
Je t'ai donne un exemple, j'aimerais bien que tu me dises comment gerer cet exemple sans verifier la valeur de retour de malloc :
[longueur du buffer decompresse: 4 octets][buffer compresse]
Tu dois allouer le buffer de destination pour decompresser le buffer, comment tu verifies si le champs longueur est OK ? La reponse est simple: tu ne peux pas, tout ce que tu peux faire est essayer d'allouer la taille demandee, retourner une erreur si ca ne marche pas, et t'assurer quand tu decompresses que tu ne depasses pas la taille allouee.
Mais si tu as un meilleur moyen, fais seulement, eclaires ma lanterne.
Tes bornes dans la serialisation elles vont servir a quoi ? A rien. Tu devrais voir a quoi ressemblent les failles de securite dans les formats :
a) Je modifies un champs pour y mettre une valeur inattendue
b) Je recalcules les checksums, etc… quand il y en a
c) J'envoies le fichier a un gars
d) A la lecture du fichier, le soft explose en vol
Le format du fichier ne peut pas etre de confiance car il vient de l'exterieur. La seule chose sur laquelle tu peux compter c'est ton propre code.
B) Tu as pose le code d'init toi-meme : Il fait un loop en verifiant si l'alloc reussit et si non il attend et re-essaie. Si on ecrivait cela comme nombre de gens ici le suggerent, init crasherait au 1er alloc qui rate.
a) Oui, si dans ton fichier les seuls bytes modifies sont ceux du champs 'longueur', tu vas faire quoi pour verifier si c'est corrompu ? Comment tu vas faire pour savoir que ton tableau compresse il ne fait pas 0x101fe040 bytes une fois decompresse mais 0x001fe040 bytes ? Donnes moi la reponse si tu la connais…
Les allocations par chunk ca marche uniquement quand il est acceptable d'avoir les donnees en blocs separes, pour une image par exemple c'est souvent pas acceptable car ca complique enormement les manipulations sur les pixels sans parler du fait que ca empeche l'affichage…
Quand a mapper le fichier, si le contenu est compresse, ca te fait une belle jambe de le mapper…
b) Tu as montre toi meme le code d'init qui verifie la valeur de retour de malloc…
Pour Windows t'as pas besoin de sources, suffit de desassembler, regarder les instructions apres l'appel a malloc et voir qu'il fait une comparaison sur le registre eax qui est l'endroit ou la valeur de retour se trouve.
je comprends pas que tes commentaires soient autant surnotés, si tu codes comme un goret, et que tu mets directement ce que tu scannes en paramètre d'un malloc, un fichier corrompu fera craché ton programme même avec un malloc de 100 qui va réussir
Lorsque tu lis le fichier, et que le format te dit que le champs 'longueur' du tableau est de 4 octets, tu vas faire quoi comme test dessus pour savoir ou non si tu fais l'allocation ? C'est quoi la valeur maximale a accepter ? Tu pourrais bien verifier la taille du fichier d'abord, mais ca ne marche pas si c'est un tableau en sortie de decompression (tu ne connais pas le % de compression) ou qui vient d'un stream genre socket reseau…
Personne n'a sorti un exemple de code critique qui gérait spécifiquement le cas malloc retourne null.
Tu regardes l'OS que tu utilises et celui qui represente 90% du marche desktop, il en sont rempli.
Donc tu vas faire des checks seulement la moitie du temps dans ton code ? Tu vas te retrouver avec un code qui se comporte correctement la moitie du temps et qui explose l'autre moitie ? Tu vas te poser la question a chaque fois de ce que tu dois faire (verifier ou pas) plutot que simplement le faire systematiquement ?
Desole mais je ne vois vraiment pas ce que t'y gagne.
Je n'ai jamais chargé un fichier avec malloc directement, j'aimerais que tu m'expliques le rapport entre allouer une zone mémoire et un fichier. Tu charges le fichier avec fopen normalement… Or je ne parle que de malloc ici.
Quand tu charges des donnees d'un fichier, tu les stockes ou ? En memoire le plus souvent, memoire qu'il faut allouer.
Je parle d'une petite allocation de quelques octets, pas d'une matrice…
Si tu sais d'avance qu'elle est petite oui, mais combien y a t'il de cas ou tu sais de maniere garantie qu'elle sera petite ? Combien sont de taille dynamique, ou la valeur vient de l'exterieur (Content-Length header d'une requete HTTP, taille de fichier, taille de tableau lue dans un fichier, valeur specifiee par l'utilisateur, etc…)
A noter que les auteurs originels de ce systeme sont Joanna Rutkowska et Rafal Wojtczuk , qui ont notamment ete a l'origine de blue pill (rootkit a base d'hyperviseur) et red pill (methodes de detection de rootkit a base d'hyperviseur). Ce sont loin d'etre des idiots dans le domaine de la securite, la presentation de Johanna sur Blue Pill a BlackHat a notamment du avoir un sacre effet sur tout programmeur mysogine qui l'a vu, j'y etais et probablement les 8 ou 9 dixiemes de la salle etaient incapable de suivre tellement c'etait bas niveau et avance (moi compris).
Ton app charge un fichier qui il se trouve est corrompu.
Le format contient quelque chose du genre [taille du tableau][tableau]
Ton app, pour charger le tableau va lire la taille et essayer de faire une allocation pour y stocker le tableau. Si la taille est corrompue (genre 0xFFFFFF0 ou autre truc enorme), ton soft va essayer de faire une allocation enorme, qui va rater meme si ta machine a encore plein de RAM dispo.
Est-ce que le soft devrait planter dans un cas pareil ? Non, il devrait voir qu'il n'arrive pas a lire le fichier et renvoyer une erreur a l'utilisateur mais si on lit certains ici, planter est la solution parait-il…
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement
Ca existe deja, suffit de reutiliser(Win32 en contient des centaines par exemple).
Ça veut dire aussi qu'il faut convertir tous les cas d'erreurs des libs externes qu'on appelle.
Oui et non, ca depend de la granularite des erreurs que tu veux gerer, et sous Windows au moins c'est souvent transparent vu qu'il y a "une" liste standard d'erreurs.
Cela étant dit, je tends plutôt vers une approche à la Zenitram: au quotidien, très peu de soft que j'écris est critique, on est soit dans la ligne de commande, soit dans l'appli graphique à deux balles. Et donc la gestion de ce genre d'erreur me passe un peu au dessus.
Je veux bien que ce soit pas critique dans ce cas, mais faire cela :
a) T'empeche de reutiliser ce que tu as ecrit dans quelque chose de plus important
b) Te donne des mauvaises habitudes je dirais, qui rende l'ecriture de code "critique" plus risque
Mon point de vue est que ces checks sont de toute facon tres rapide a ajouter(il y a quasiment toujours des chemins d'erreurs pour d'autres raisons, suffit donc de les reutiliser) et qu'au final cela coute tellement peu a faire qu'il vaut mieux le faire systematiquement.
[^] # Re: Outrage against the machine
Posté par pasBill pasGates . En réponse au journal SuSE Linux en pleine forme grâce à Attachmate. Évalué à -6.
Ben je lis cette info regulierement, alors j'ai cherche 30 secondes, trouve un lien demontrant que des gens faisant des comptes assez serieux disent de meme, et voila, j'allais pas te faire une analyse profonde sur 20 pages quand meme :)
Pour ce qui est du "vrai cout de windows", ben tu trouveras plein de gens te disant que ce vrai cout, il est plus bas que le concurrent d'en face quand tu mesures la totalite…
[^] # Re: Outrage against the machine
Posté par pasBill pasGates . En réponse au journal SuSE Linux en pleine forme grâce à Attachmate. Évalué à -4.
Pour les serveurs web, si tu regardes le meme site reference dans ce journal, il montre Windows a 30% du marche des serveurs web public, eh oui, il n'y a pas que IIS comme serveur web sous Windows !
http://arstechnica.com/business/2011/09/despite-enterprise-dominance-microsoft-struggles-in-web-server-market/
According to IDC, Windows Server accounted for 71 percent of all second quarter server shipments, with revenue of $5.9 billion representing 45.5 percent of worldwide revenue. The rest of the market is split among Linux, mainframes, Unix and others.
[^] # Re: Outrage against the machine
Posté par pasBill pasGates . En réponse au journal SuSE Linux en pleine forme grâce à Attachmate. Évalué à -3.
Quel marche ? Celui des serveurs en general ? Celui la oui c'est sur que MS le domine.
Celui des serveurs web publics par contre, c'est tres probablement l'inverse.
[^] # Re: Résumé des commentaires du journal
Posté par pasBill pasGates . En réponse à la dépêche Intel ne supportera pas Linux pour ses Clover Trail. Évalué à 2.
Comme toutes les tablettes Win8, arm y compris, Microsoft impose de locker le HW par DRM
C'est faux. Microsoft impose de pouvoir unlocker les tablettes x86, et impose de locker les ARM.
[^] # Re: Comme quoi...
Posté par pasBill pasGates . En réponse au journal Google et Alibaba un autre point de vue que celui de Microsoft. Évalué à -4.
a) Tu as le contrat avec OHA ? Moi je l'ai pas et il n'est pas sur le site de l'OHA non plus
b) Tu en sais quoi que le contrat de MS n'etait pas le meme avec tous les OEMs ? Rien
c) Oui tout a fait, Acer peut utiliser Aliyun, tout comme Hitachi (je crois que c'etait eux) pouvait utiliser BeOS. Acer devra faire sans support, ce qui augmente leur couts, et Hitachi aurait du faire avec un Windows un peu plus cher, ce qui augmente leurs couts, quelle difference…
Amazon a simplement tire avantage du fait que Android est libre et cela marche pour eux car ils n'ont jamais eu l'intention d'avoir Android de Google, Google n'a aucun moyen de pression sur eux, contrairement a Acer.
[^] # Re: Le libre, mais en fait non
Posté par pasBill pasGates . En réponse au journal Google et Alibaba un autre point de vue que celui de Microsoft. Évalué à -3.
Compares ca a MS qui ferait payer un OEM plus cher sa copie de Windows compare aux autres OEMs… Exactement ce qui est arrive et qui a value un sacre merdier a MS.
Enlever l'acces en avance et le support, ca revient exactement au meme que ce que MS avait fait. Le seul truc qui sauve Google pour l'instant est qu'ils ne sont pas un monopole.
[^] # Re: Comme quoi...
Posté par pasBill pasGates . En réponse au journal Google et Alibaba un autre point de vue que celui de Microsoft. Évalué à -1.
Devines quoi, MS aussi avait des contrats avec ses OEMs… Tu ne peux pas mettre tout et n'importe quoi dans un contrat.
[^] # Re: Comme quoi...
Posté par pasBill pasGates . En réponse au journal Google et Alibaba un autre point de vue que celui de Microsoft. Évalué à -2.
Ma reponse est simple: Si cela avait ete MS, il se serait pris un proces pour abus de monopole.
Ici Google fait de meme avec un OS qui a 60% du marche…
Faire partie de "OHA" est essentiel pour tout constructeur de smartphone qui veut faire de l'Android. Les regles de l'OHA, j'en comprends une partie, mais je les trouves sacrement limite en ce qui concerne l'interdiction de vendre un fork "incompatible avec Android". Ils ne limitent pas les constructeurs a tous les autres OS, mais une partie specifique. Maintenant je comprendrais qu'ils disent "ne dites pas que ces OS sont compatible-Android", mais qu'ils interdisent l'utilisation de l'OS forke tout simplement c'est extreme de mon point de vue.
Pour le reste, Alibaba n'a aucune excuse en ce qui concerne les softs pirates, c'est inacceptable (et ca a toujours ete un des problemes d'Android, je ne comprends pas que Google ne fasse rien contre).
[^] # Re: Comme quoi...
Posté par pasBill pasGates . En réponse au journal Google et Alibaba un autre point de vue que celui de Microsoft. Évalué à 0.
Tout personne assumant que ce que je dis represente MS a tout le temps tort.
[^] # Re: Les auteurs
Posté par pasBill pasGates . En réponse à la dépêche QubesOS 1.0. Évalué à 0.
Peut-etre un petit peu oui, c'etait a un niveau technique tellement eleve que la plupart de la salle ne pouvait pas suivre car n'avait pas les connaissances necessaires.
[^] # Re: Mais non :-p
Posté par pasBill pasGates . En réponse au journal Do no evil qu'ils disaient. Évalué à 0.
"Acer will continue to communicate with Google and the company still wants to launch the new smartphone based on Alibaba software," an official at Acer, who declined to be named, said.
[^] # Re: Inéluctable
Posté par pasBill pasGates . En réponse au journal Do no evil qu'ils disaient. Évalué à 0.
Ce n'est nullement de la haine. Mirosoft en lui-même m'indiffère
Vu ta propension a focaliser sur MS dans tes critiques sans faire le moindre effort pour relativiser ce qu'ils font, si c'est de la haine.
Jusque dans les milieux libristes, ils ont réussi à instiller une pensée lénifiante, masquant dans l'esprit des gens la réalité de leur entreprise. Quiconque y réfléchit posément ne peut que se rendre compte qu'ils demeurent, bien plus que nombre de leur concurrents (pomme notamment) l'un des principaux obstacles au libre, et partant une nuisance majeure pour l'économie mondiale.
Bonjour Mr Stallman, comment se porte votre religion aujourd'hui ?
Desole, mais tu ne fais que confirmer ce que je dis plus haut dans cette phrase : tu as un comportement aveugle et uniquement dicte par un dogme(le libre ou la mort).
Malheureusement, cette réalité tient à l'objet sociale de la compagnie. Objet qui ne souffre pas la moindre pondération morale, même de pur principe, comme pour google. Du coup, aucun espoir n'est permis en la matière. Et c'est bien dommage étant donné les trésors techniques qu'accumule microsot. Un pas d'humanité, si proche, si cours, si aisé, et qui pourtant ne sera jamais accompli, suffirait à les emmener du nadir au zénith.
Et tu continues en parlant de MS sans aucun principe moral, alors que parait-il Google oui. Sachant que tu n'as jamais mis les pieds dans aucune des 2 societes.
[^] # Re: Mais non :-p
Posté par pasBill pasGates . En réponse au journal Do no evil qu'ils disaient. Évalué à 2.
Acer veut utiliser un fork ET Android.
Que Google ne veuille pas faire le support du fork, je le comprends totalement. Qu'ils disent a Acer "abandonnez vos projets sinon on coupe notre support Android" par contre, pas trop.
[^] # Re: Mais non :-p
Posté par pasBill pasGates . En réponse au journal Do no evil qu'ils disaient. Évalué à 0.
Tu aurais presque raison, a part le fait qu'ici l'info vient directement d'officiels d'Alibaba ET Acer qui sont cites anonymement. C'est pas simplement Alibaba, concurrent de Google, ou des fanboys imaginant ce qu'ils veulent, et c'est toute la difference.
Pour les pressions, elles sont surement differentes vu la nature du produit oui, mais enlever le support a Acer revient effectivement a les forcer a forker et supporter un OS seuls, ce qui augmente enormement leurs couts et rend la vente de smartphones Android a prix concurrentiel impossible.
[^] # Re: Inéluctable
Posté par pasBill pasGates . En réponse au journal Do no evil qu'ils disaient. Évalué à 5.
Lucide ? Tu me fais bien rire.
Il suffit de lire des aneries genre :
Entre d'une part une firme dont les contributions positives pour le progrès sont inexistantes ou du moins négligeables et largement ignorées, et d'autre part une compagnie encore présentement au sommet inégalé d'une activité qui a révolutionné le monde. Peut-être est-ce dû aux principes diamétralement opposés ? du « do no evil » au culte des méthodes commerciales, l'abîme est insondable
et
spécial dédicace à la B.&M. G. F. et, par exemple, à ses financement hasardeux d'essais cliniques chimiques in-vivo sur des populations en deshérence ; mais aussi aux multiples craques qu'engendre la concentration
Pour se rendre compte a quel point tu as une haine de tout ce qui touche de pres ou de loin a MS sans aucune echelle de valeur. Tes mots sont a une extreme tellement absurde qu'ils ne valent absolument rien.
Reviens nous voir une fois que tu auras compare de maniere posee les bienfaits et mefaits de MS/Google et la fondation Gates plutot que vociferer une haine aveugle.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à -2.
1) Je te suggeres de rester poli, surtout que tu as faux sur toute la ligne, et on est plusieurs a te le dire.
2) Le code serialisant des objets, les conteneurs video, etc… ont tous ces problemes, je te suggeres d'aller regarder les patches pour failles de securite dans libjpeg / libpng etc… cf. http://blog.cr0.org/2009/05/write-once-own-everyone.html par exemple.
3) Il y en a , tu l'as montre toi meme : attendre est de la gestion d'erreur, tu verifies la valeur retournee et tu evites un crash. Quelqu'un d'autre t'as montre plus bas qu'Inkscape gerait cela aussi et plein d'autres softs font de meme
Maintenant regardes ce qu'il se passe dans le imalloc de init au cas ou un autre goret coderait comme toi : ça part en boucle infinie! Mais c'est pas génial ça!
Tu es un sacre clown quand meme, tu as vu ou que j'ecrirais un code qui part en boucle infinie ? Tu as deja vu mon code ?
La difference entre toi et moi c'est que moi mon code tourne sur un milliard de machines, y compris des serveurs surcharges, et la plupart du temps sans probleme. Toi tu es visiblement bon pour insulter les gens, et beaucoup moins pour comprendre comment programmer proprement.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à -2.
De nouveau non tu ne comprends rien, le checksum ou le marqueur ne changent rien
A) Si je veux t'attaquer, je peux t'envoyer un fichier avec un mauvais champs longueur et une checksum correcte. Mais c'est de toute facon pas important parce que si le format du fichier ne comprend pas de checksum ou de marqueur, ben voila, tu ne peux pas en rajouter, tout simplement car le format n'en a pas et tu aurais des lors un fichier non conforme.
b) Ecraser le buffer n'est pas le probleme
Rien ne t'empeche de traiter ca correctement, tu sais que tu as alloue 100'000 bytes, suffit de t'assurer que tu n'ecris pas plus de 100'000 bytes quand tu decompresses et retourner une erreur si il y a des donnees restantes.
Ici, avant meme de commencer a decompresser, ton malloc a de tres grandes chances de retourner NULL sur x86 et tu vas exploser immediatement si tu ne verifies pas la valeur de retour.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 1.
A) Mais de nouveau, si le parametre 'longueur' est corrompu, comment tu le sais quand tu lis ton fichier ?
Je t'ai donne un exemple, j'aimerais bien que tu me dises comment gerer cet exemple sans verifier la valeur de retour de malloc :
Tu dois allouer le buffer de destination pour decompresser le buffer, comment tu verifies si le champs longueur est OK ? La reponse est simple: tu ne peux pas, tout ce que tu peux faire est essayer d'allouer la taille demandee, retourner une erreur si ca ne marche pas, et t'assurer quand tu decompresses que tu ne depasses pas la taille allouee.
Mais si tu as un meilleur moyen, fais seulement, eclaires ma lanterne.
Tes bornes dans la serialisation elles vont servir a quoi ? A rien. Tu devrais voir a quoi ressemblent les failles de securite dans les formats :
a) Je modifies un champs pour y mettre une valeur inattendue
b) Je recalcules les checksums, etc… quand il y en a
c) J'envoies le fichier a un gars
d) A la lecture du fichier, le soft explose en vol
Le format du fichier ne peut pas etre de confiance car il vient de l'exterieur. La seule chose sur laquelle tu peux compter c'est ton propre code.
B) Tu as pose le code d'init toi-meme : Il fait un loop en verifiant si l'alloc reussit et si non il attend et re-essaie. Si on ecrivait cela comme nombre de gens ici le suggerent, init crasherait au 1er alloc qui rate.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à -1.
a) Oui, si dans ton fichier les seuls bytes modifies sont ceux du champs 'longueur', tu vas faire quoi pour verifier si c'est corrompu ? Comment tu vas faire pour savoir que ton tableau compresse il ne fait pas 0x101fe040 bytes une fois decompresse mais 0x001fe040 bytes ? Donnes moi la reponse si tu la connais…
Les allocations par chunk ca marche uniquement quand il est acceptable d'avoir les donnees en blocs separes, pour une image par exemple c'est souvent pas acceptable car ca complique enormement les manipulations sur les pixels sans parler du fait que ca empeche l'affichage…
Quand a mapper le fichier, si le contenu est compresse, ca te fait une belle jambe de le mapper…
b) Tu as montre toi meme le code d'init qui verifie la valeur de retour de malloc…
Pour Windows t'as pas besoin de sources, suffit de desassembler, regarder les instructions apres l'appel a malloc et voir qu'il fait une comparaison sur le registre eax qui est l'endroit ou la valeur de retour se trouve.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 3.
je comprends pas que tes commentaires soient autant surnotés, si tu codes comme un goret, et que tu mets directement ce que tu scannes en paramètre d'un malloc, un fichier corrompu fera craché ton programme même avec un malloc de 100 qui va réussir
Lorsque tu lis le fichier, et que le format te dit que le champs 'longueur' du tableau est de 4 octets, tu vas faire quoi comme test dessus pour savoir ou non si tu fais l'allocation ? C'est quoi la valeur maximale a accepter ? Tu pourrais bien verifier la taille du fichier d'abord, mais ca ne marche pas si c'est un tableau en sortie de decompression (tu ne connais pas le % de compression) ou qui vient d'un stream genre socket reseau…
Personne n'a sorti un exemple de code critique qui gérait spécifiquement le cas malloc retourne null.
Tu regardes l'OS que tu utilises et celui qui represente 90% du marche desktop, il en sont rempli.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 2.
Donc tu vas faire des checks seulement la moitie du temps dans ton code ? Tu vas te retrouver avec un code qui se comporte correctement la moitie du temps et qui explose l'autre moitie ? Tu vas te poser la question a chaque fois de ce que tu dois faire (verifier ou pas) plutot que simplement le faire systematiquement ?
Desole mais je ne vois vraiment pas ce que t'y gagne.
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 0.
Je n'ai jamais chargé un fichier avec malloc directement, j'aimerais que tu m'expliques le rapport entre allouer une zone mémoire et un fichier. Tu charges le fichier avec fopen normalement… Or je ne parle que de malloc ici.
Quand tu charges des donnees d'un fichier, tu les stockes ou ? En memoire le plus souvent, memoire qu'il faut allouer.
Je parle d'une petite allocation de quelques octets, pas d'une matrice…
Si tu sais d'avance qu'elle est petite oui, mais combien y a t'il de cas ou tu sais de maniere garantie qu'elle sera petite ? Combien sont de taille dynamique, ou la valeur vient de l'exterieur (Content-Length header d'une requete HTTP, taille de fichier, taille de tableau lue dans un fichier, valeur specifiee par l'utilisateur, etc…)
# Les auteurs
Posté par pasBill pasGates . En réponse à la dépêche QubesOS 1.0. Évalué à 10.
A noter que les auteurs originels de ce systeme sont Joanna Rutkowska et Rafal Wojtczuk , qui ont notamment ete a l'origine de blue pill (rootkit a base d'hyperviseur) et red pill (methodes de detection de rootkit a base d'hyperviseur). Ce sont loin d'etre des idiots dans le domaine de la securite, la presentation de Johanna sur Blue Pill a BlackHat a notamment du avoir un sacre effet sur tout programmeur mysogine qui l'a vu, j'y etais et probablement les 8 ou 9 dixiemes de la salle etaient incapable de suivre tellement c'etait bas niveau et avance (moi compris).
[^] # Re: Je pense que tu confonds les cas où c'est nécessaire
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 1.
Ton app charge un fichier qui il se trouve est corrompu.
Le format contient quelque chose du genre [taille du tableau][tableau]
Ton app, pour charger le tableau va lire la taille et essayer de faire une allocation pour y stocker le tableau. Si la taille est corrompue (genre 0xFFFFFF0 ou autre truc enorme), ton soft va essayer de faire une allocation enorme, qui va rater meme si ta machine a encore plein de RAM dispo.
Est-ce que le soft devrait planter dans un cas pareil ? Non, il devrait voir qu'il n'arrive pas a lire le fichier et renvoyer une erreur a l'utilisateur mais si on lit certains ici, planter est la solution parait-il…
[^] # Re: Et printf ?
Posté par pasBill pasGates . En réponse au journal Genèse d'un journal. Évalué à 3.
Ça suppose quand même d'avoir une grande base de code d'erreurs unifiés pour permettre la propagation assez simplement
Ca existe deja, suffit de reutiliser(Win32 en contient des centaines par exemple).
Ça veut dire aussi qu'il faut convertir tous les cas d'erreurs des libs externes qu'on appelle.
Oui et non, ca depend de la granularite des erreurs que tu veux gerer, et sous Windows au moins c'est souvent transparent vu qu'il y a "une" liste standard d'erreurs.
Cela étant dit, je tends plutôt vers une approche à la Zenitram: au quotidien, très peu de soft que j'écris est critique, on est soit dans la ligne de commande, soit dans l'appli graphique à deux balles. Et donc la gestion de ce genre d'erreur me passe un peu au dessus.
Je veux bien que ce soit pas critique dans ce cas, mais faire cela :
a) T'empeche de reutiliser ce que tu as ecrit dans quelque chose de plus important
b) Te donne des mauvaises habitudes je dirais, qui rende l'ecriture de code "critique" plus risque
Mon point de vue est que ces checks sont de toute facon tres rapide a ajouter(il y a quasiment toujours des chemins d'erreurs pour d'autres raisons, suffit donc de les reutiliser) et qu'au final cela coute tellement peu a faire qu'il vaut mieux le faire systematiquement.