Роман Химов

Именно за такой подход я уважаю разработчиков ОпенБСД. Да, у них приблизительно миллион разных проблем, которые со стороны Линукса кажутся смешными, но у них есть совершенно чёткие приоритеты и в этих заданных приоритетах они реально делают всё возможное, чтобы получить достойный результат. Даже если для этого нужно форкнуть ОпенССЛ.

А форкнуть ОпенССЛ, видимо, надо было уже давно. Я неоднократно лазил внутрь него и даже кое-что делал, ничего кроме адского кошмара там нет. При наличии возможности выбора, просто брал ГнуТЛС. Но возможность такая есть не всегда, поскольку все уже привыкли лепить костыли вокруг ОпенССЛа и переделывать их, как водится, никто не собирается.

Конечно, ещё больше нравится нечто типа Содиума, когда библиотека изначально пишется людьми в теме, но применимость Содиума на данный момент, увы, слаба.

На данный момент говорят о 90 000 выпиленных строк кода без потери совместимости, это при том, что там всего их около 335 000 (включая автогенерируемые файлы). Грубо говоря, треть кода — мусор. Значит, скорее всего, можно ещё тысяч 50 выпилить. А если ещё начать работать над интерфейсом библиотеки, то совсем туши свет.

Это, по опыту, очень характерная для ёпен сорсных проектов вещь — обрастание хрен пойми чем со временем. Особенно этому способствует непостоянство команды разработчиков и слабое ревью изменений, или, проще, та самая неорганизованность разработки. Вроде как все решают какие-то вполне конкретные проблемы и несут добро и пользу, но каждый решает проблемы свои и по-своему, а когда все решения собираются в кучу — получается миллион костылей, массовое дублирование кода и отсутствие хоть сколь-нибудь вменяемой архитектуры.

Справедливости ради, при наличии способствующих обстоятельств, тот же эффект отлично воспроизводим и вне ёпен сорса. Поэтому, в конечном счёте, без грамотной команды разработчиков с общим пониманием целей и средств, хорошее получается редко.

По счастью, именно с командой у ОпенБСД проблем нет, что и позволяет надеяться на достойный результат.

Полтора года прошло с момента обнаружения утечки рутового сертификата компании DigiNotar. В своё время история наделала немало шума, все посуетились, повыпускали заплаток, попрыгали и успокоились. С того времени были ещё схожие случаи, ну да и ладно, тоже что-то патчилось, обновлялось, блокировалось, всё чудесно.

А тут мне понадобилось посмотреть на патчи Debian для openssl и, глядь, вот он, block_diginotar.patch. Заглянул, чисто из интереса, посмотреть и слегка прибалдел. Патч просто-напросто блокирует все сертификаты в поле CN которых содержится подстрока «DigiNotar». Там, конечно, написано, на всякий случай, что «This is not meant as final patch.», но тем не менее, именно оно в стабильном Debian. И даже более того, пользуясь таким отличным примером, аналогичным образом был заблокирован малазийский Digicert.

Технически можно было просто удалить сертификаты из хранилища рутовых сертификатов поддерживаемого дистрибутивом. Можно было, если уж хочется понадёжнее, опереться на отпечаток (хэш) сертификата. Ну уж в самом крайнем случае полный сабжект сертификата, хотя тоже нехорошо. Но вместо этого имеем даже не заблокированные CN, а просто запрещённые слова в CN. На которые, в принципе, можно и случайно наткнуться, а потом долго гадать, почему получается вот так:

rik@sencha:~/CA$ openssl verify -CAfile cacert.pem cacert.pem 
cacert.pem: /O=The Sample Company/L=Metropolis/ST=New York/C=US/CN=No, it's not a DigiNotar
error 23 at 0 depth lookup:certificate revoked

А оно так и получается, если воспользоваться простейшим мануалом по развёртыванию УЦ и правильно угадать с CN.

Что характерно, в той же openSUSE таких костылей нет и аналогичный сертификат живёт без проблем. Интересно, как оно в других дистрибутивах. Может, это у Debian карма такая, с кривым openssl жить?