FWIW, я абсолютно не согласен с тем, как команда OpenSSL решена heartbleed ошибка.
Кулак всего, сама проблема возникает проблема не в это изменение, но в это один (или, может быть, даже раньше, когда они ввели внутреннюю кучу памяти, к библиотеке).
"Память сохранения патч" - действительно?
Этот парень завернул его очень хорошо: http://article.gmane.org/gmane.os.openbsd.misc/211963

Если бы они не представили собственную кучу для OpenSSL, в первую очередь, это heartbleed ошибка была бы причиной нарушения доступа к памяти, и этот вопрос будет замечен долго эго.
Кроме того, единственная причина для Lib безопасности, чтобы иметь свой собственный менеджер кучи, чтобы обеспечить более высокий уровень безопасности - это означает: убедитесь, чтобы очистить всю память, освобождая ее.
То, что это куча делает вместо того, чтобы действительно убедиться, что память не очищается, независимо от того, как вы построили LIB!
Так любой буфер вы выделяете, в любой функции, есть достойные изменения, которые вы получите его заполнены некоторые важные данные, как частный ключ, используемый только минуту назад.
И поэтому, зная жизнь, я почти уверен, что есть и другие функции, которые просачиваются приватные данные из внутренней кучи OpenSSL, - его просто вопрос времени, прежде чем кто-то находит их.

Правильный способ решить эту проблему было фиксируя внутреннюю кучу (сделать это, чтобы очистить память во время освобождения), или просто удалить его, потому что не нужно было в первую очередь.
Но окончательно не просто фиксируя его как это, абстрагируясь от реальной первопричины.

С другой стороны, это разработчик (который использует эту ОМТ) обязанность очистить все важные данные из памяти, перед освобождением любого буфера, который будет содержать его, и предпочтительно даже раньше; как только решающие данные больше не нужны.
Но, видимо, только немногие разработчики на самом деле сделать это и Bitcoin основного devels, кажется, не быть в этом списке ... наконец, насколько я проверил этот код.
Так, позор вам тоже!