К новости о внедрении Taskotron хочется сказать, что тестирование в рамках дистрибутива мало кем ведется. Например, в рунете исторически роль бета-тестера почему-то используется, как оскорбление - нас регулярно пытаются в этом обвинить не очень далекие люди. У нас, конечно, видение ситуации отличается, и в том, что наш продукт тестируется, мы не видим ничего позорного, и даже регулярно проводим тестовые дни.

В других коммьюнити вокруг открытых проектов потихоньку меняют свои взгляды на тестирование. Например, не так давно тесты появились даже в ядре Linux, которое до этого никто не тестировал вообще (даже после появления тестов никто особо его не тестирует). Но вот в рамках дистрибутивов пока очагов тестирования немного. Навскидку вспоминается инженер Canonical и разработчик systemd, Martin Pitt, который проводит какую-то нечеловеческого объема работу по созданию тестов уровня пользователя, уже упомянутые наши тестовые дни, и еще есть секретная лаборатория в подвалах дата-центров Red Hat. В этих подвалах наши коллеги ведут тестирование прикладного ПО, в т.ч. и на уровне GUI, о чем был интересный доклад на прошедшем FOSDEM 2014, который некоторые наши участники посетили лично. А в вашем дистрибутиве есть тестирование?

Огромный объем тестирования, проводимый в Red Hat, предсказуемо приводит к недавно анонсированному результату - 17% уязвимостей в безопасности выявляются самими инженерами Red Hat, а почти 27% они узнают по знакомству, что примерно тоже самое. Уязвимость, выявленная "по знакомству", это порой та же уязвимость, найденная лично, просто после обнаружения ошибки дополнительно приходится консультироваться с upstream, чтоб разобраться в причине. Все это это и приводит к более большому уровню надежности RHEL по сравнению с конкурентами, которые получают информацию об уязвимостях лишь после анонсирования их в интернете (вот зачем нужно брать на работу разработчиков, а не только дизайнеров, переносящих кнопки справа налево и обратно).

Но, конечно, коллеги-аналитики верно подметили, что нашими и делается ошибок тоже навалом. Например, в grep обычно происходит так - вносится улучшение, которое только все портит, а в следующей версии уже исправляется внесенное улучшение (см. grep 2.18 и grep 2.20). Бывает, чего уж. Сперва добейся, а потом критикуй!

Само собой, не только у нас заботятся о безопасности - половину других уязвимостей ведь кто-то находит. В дружественной нам компании Collabora тоже занимаются безопасностью системных компонентов, например устраняют ошибки в D-Bus. Их инженер, Alban Crequy, в своем блоге подводит итог последних месяцев работы по улучшению безопасности D-Bus. Как вы знаете, наши друзья и коллеги планируют перенести его функционал в ядро Linux, поэтому эта работа довольно интересна для нас.