о хитром коде (программистское)

[avva]

Интересная блог-запись, подытоживающая фиаско с ssh-ключами в Дебиан.

Кроме того, что там подробно все объясняется, есть еще список советов разработчикам. Из них самый важный, по-моему, и тот, который на практике чаще всего игнорируют --

Don't write clever code.

Год или два назад у меня была подробная запись о том, что я не вполне уверен, что сейчас я лучший программист, чем был, скажем, 10 или 13 лет назад. Не уверен в том, что вообще есть накопление программистского мастерства и умения. Но вот это правило - пример чего-то, что я не знал и не понимал как следует десять и даже пять лет назад, по-моему. Если есть что-то, что я усвоил за последние несколько лет в своей профессии и что можно назвать фундаментально важным, то это оно - последовательное и принципиальное понимание и использование этого правила.

Comments

[msh.livejournal.com]

Мне непонятна в чем вина программиста OpenSSL

Есть очевидная проблема с Debian - уровень maintainers очень разный и часто, прямо скажем, весьма низкий. Ну не самое интересное занятие-то перепаковывать чужой софт, там обычно молодые сисадмины с избытком свободного времени

Maintainer полез копаться в криптографии не понимая что к чему и сломал. Никто больше этого не сделал, потому что при мало-мальски существующем контроле этот код не достался бы человеку с такой квалификацией и изменение кода "чтобы заткнуть valgrind" никогда никто бы не одобрил

В принципе, это частая проблема с open source который именно пишется толпой, а не строго контролируется, как линуксный кернел, и не пишется на самом деле какой-то конторой с существующим development process

А код нормальный, надо как раз стараться писать clever code если выходит, тупой и так есть кому написать

[avva.livejournal.com]

Его код был написан неряшливо, без какой-либо причины использовал неинициализированную память (энтропии это не добавляет, по крайней мере качественной), более важные vs менее важные источники энтропии не было документированы в коде.

[msh.livejournal.com]

Я посмотрел код - ну да, написан он малопонятно, почему буфер не инициализирован не написано (сколько это дает энтропии - я не знаю, может и не дает и смысла не имеет). Если бы дебиановец инициализировал бы этот буфер в rand_unix, то это можно было бы списать на непонятность кода, но он-то сломал RAND_add() которая не просто документирована, но даже имеет man page

[pargentum.livejournal.com]

В неинициализированной памяти как правило непропорциональное количество нулей. Часто она вообще вся забита нулями, а если там не нули, то часто это вполне фиксированные значения, надежно воспроизводящиеся при каждом прогоне программы (т.е. с точки зрения отладки это редко, а вот с точки зрения энтропии - это как раз наоборот очень часто).
Как я понимаю, дебиановец ошибочно решил, что где-то в другом месте зовется нормальный RAND_add() с нормальным источником энтропии.

[msh.livejournal.com]

Ответ "там непропорциональное количество нулей" не отвечает на вопрос "сколько там энтропии". Что энтропии там меньше чем в полностью случайной последовательности - это очевидно. И, кстати, нет, там может быть что угодно в зависимости от того как мы его получаем. Например, мы генерируем ключ всегда в одной и той же точке программы и получаем от аллокатора (или со стека) всегда один и тот же кусок только что освобожденный кем-то другим, содержащий одно и тоже.

Но это все равно moot point, потому что дебиановец не смог понять не почему данные не инициализируют, а как работает RAND_add и убрал из нее главную строчку - где энтропию в дайджест добавляют.

[pargentum.livejournal.com]

Все-таки использовать неинициализированную память как источник энтропии - ... Если бы у меня в проекте такое написали, я бы точно постарался по башке настучать. И тому, кто написал, и тому, кто закоммитил.

То есть хороши, конечно, оба - и openssl разработчик, и дебиановский майнтайнер. Но майнтайнера хотя бы можно по человечески понять - я бы тоже не ожидал обнаружить в коде уважаемой библиотеки такую фигню, а если бы обнаружил, то тоже решил бы, что это какая-то очень эзотерическая вещь для какого-нибудь очень эзотерического сочетания ОС, компилятора и требований, которую можно без большого вреда задизаблить. А со стороны OpenSSL это было чистое и ничем не оправдываемое вредительство.

[mirritil.livejournal.com]

самая главная вина в их раздолбайских ответах в списке рассылки, и одобрение изменения.