Arrêtes de répéter ça, ce n'est pas vrai.
Certainement plus que dire (répeter jusqu'a plus soif devrais je dire)
"il savait absolument pas ce qu'il faisait", vu qu'il a pointé du doigt le problème d'entropie du code.
Et si c'est vrai, c'est uniquement pour une version de debug.
pas totalement vrai ce que tu dis, il acceptait pour le debugging AUSSI des applications contenants openssl.
Regardons donc les liens que j'ai donné, on voit : Not much. If it helps with debugging, I'm in favor of removing them.
> (However the last time I checked, valgrind reported thousands of bogus
> error messages. Has that situation gotten better?)
I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
GNU/Linux 'sid' with valgrind version 3.1.1 was able to debug some
application using both TLS/SSL as S/MIME without any warning or error
about the OpenSSL code. Without -DPURIFY you're indeed flooded with
warnings.
So yes I think not using the uninitialized memory (it's only a single
line, the other occurrence is already commented out) helps valgrind.
Oh tiens ca alors, ca parle pas que du debugage interne à openssl mais aussi de tous les autres codes qui utilisent openssl (et qui donc ne travaillent pas sur une version d'openssl de debug. Quand tu debug ton code, tu travaille pas sur une version de debug de libc6 , si ?)
alors je suis d'accord que le dvp debian a fait des merdouilles, que les dev d'openssl ont pas forcément vu tous les problèmes, mais un moment faut arrêter de dire "Il sait absolument pas ce qu'il faisait", et "il a tout fait tout seul dans son coin".
Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
Pas forcément : il n'y a pas de bug a proprement parlé. La criticité de l'opération est très faible. Donc on voit passer sa sur la mailing list, on se dis "a pas con", et finalement on oublie de reporter ça. Comme ça ne corrige pas de bugs à proprement parler, on oublie relativement facilement, et on se précipite pas pour pousser tout upstream.
La ou les dvp de debian ont merdé, c'est lors du push des patchs vers l'upstream, et ca je suis bien d'accord.
[^] # Re: détails techniques et exploits
Posté par briaeros007 . En réponse au journal Vulnérabilité Debian. Évalué à 3.
Certainement plus que dire (répeter jusqu'a plus soif devrais je dire)
"il savait absolument pas ce qu'il faisait", vu qu'il a pointé du doigt le problème d'entropie du code.
Et si c'est vrai, c'est uniquement pour une version de debug.
pas totalement vrai ce que tu dis, il acceptait pour le debugging AUSSI des applications contenants openssl.
Regardons donc les liens que j'ai donné, on voit :
Not much. If it helps with debugging, I'm in favor of removing them.
> (However the last time I checked, valgrind reported thousands of bogus
> error messages. Has that situation gotten better?)
I recently compiled vanilla OpenSSL 0.9.8a with -DPURIFY=1 and on Debian
GNU/Linux 'sid' with valgrind version 3.1.1 was able to debug some
application using both TLS/SSL as S/MIME without any warning or error
about the OpenSSL code. Without -DPURIFY you're indeed flooded with
warnings.
So yes I think not using the uninitialized memory (it's only a single
line, the other occurrence is already commented out) helps valgrind.
Oh tiens ca alors, ca parle pas que du debugage interne à openssl mais aussi de tous les autres codes qui utilisent openssl (et qui donc ne travaillent pas sur une version d'openssl de debug. Quand tu debug ton code, tu travaille pas sur une version de debug de libc6 , si ?)
alors je suis d'accord que le dvp debian a fait des merdouilles, que les dev d'openssl ont pas forcément vu tous les problèmes, mais un moment faut arrêter de dire "Il sait absolument pas ce qu'il faisait", et "il a tout fait tout seul dans son coin".
Enfin, si c'était pertinant à faire, l'upstream l'aurait fait.
Pas forcément : il n'y a pas de bug a proprement parlé. La criticité de l'opération est très faible. Donc on voit passer sa sur la mailing list, on se dis "a pas con", et finalement on oublie de reporter ça. Comme ça ne corrige pas de bugs à proprement parler, on oublie relativement facilement, et on se précipite pas pour pousser tout upstream.
La ou les dvp de debian ont merdé, c'est lors du push des patchs vers l'upstream, et ca je suis bien d'accord.