Давно собирался написать про инструменты для безопасной разработки ПО, которые развивает ИСП РАН и всё откладывал. А теперь появился повод, из-за которого откладывать больше нельзя. На счету ИСП РАН есть проекты для тестирования микропроцессоров MicroTESK и тестирования ПО на основе моделей UniTESK. А последние несколько лет они ещё делают Svace [1], Crusher [2] и инструмент для символьного выполнения Sydr [3]. На базе Sydr и libfuzzer они сделали форк OSS Fuzz [4], в котором тестируют пару десятков проектов с открытым исходым кодом. Пару багов в Tarantool они уже нашли и принесли патчи с фиксами. Svace это статический анализатор, который поддерживает языки C, C++, C#, Java, Kotlin и Go и обнаруживает более 50 классов критических ошибок в исходном коде, а Crusher это комплекс динамического анализа, который состоит из инструментов для проведения фаззинг-тестирования и автоматической генерации тестов. И Svace и Crusher являются коммерческими продуктами, которые ИСП РАН развивает в тесном контакте с российскими компаниями-разработчиками системного ПО. Эти инструменты позволяют построить процессы безопасной разработки в соответствии с ГОСТ Р 56939-2016 и «Методикой выявления уязвимостей и недекларированных возможностей в программном обеспечении» ФСТЭК России. По решению руководства ИСП РАН предлагает заинтересованным российским компаниям бесплатный доступ к своим программным технологиям безопасной разработки сроком на шесть месяцев. Я вижу здесь не столько халяву, сколько возможность попробовать современные инструменты от отечественного разработчика для качественной разработки ПО.

1. https://www.ispras.ru/technologies/svace/
2. https://www.ispras.ru/technologies/crusher/
3. https://vishnya.xyz/vishnyakov-isprasopen2020.pdf
4. https://github.com/ispras/oss-sydr-fuzz

Источник: https://www.tg-me.com/scienpolicy/23646

Как и в прошлом году мы в Tarantool опять принимаем участие в Google Summer of Code. Для тех, кто не знает: это программа по поддержке проектов с открытым исходным кодом от Гугла. Как это работает: проекты, которые хотят принять участие в программе, описывают идеи для задач и подают заявку для участия. Гугл выбирает проекты для участия и публикует их список. Далее участники выбирают проекты и задачи, которые им будет интересно сделать, и подают заявки на участие в программе. Потом студенты всё лето работают над выбранной задачей при поддержке менторов из проекта и к концу срока выполнения задачи предоставляют рабочий прототип или патчи. При успешном выполнении задачи студенты получают вознаграждение от Гугла (размер вознаграждения варьируется от места проживания). Для участников из России размер стипендии варьируется от 1500$ USD до 3000$ USD. С 4 по 19 апреля участникам нужно подать заявку и после одобрения заявки можно будет выбрать проект и задачу, над которой интересно работать. Самое главное: в этом году правила участия поменялись - теперь не обязательно быть студентом или аспирантов, нужно только быть старше 18 лет.

В этот раз в идей для участников попали три задачи для тестирования Tarantool: фаззер LuaJIT, фаззер SQL и интеграция с SQLancer. Это лишь небольшая часть всех идей, которые мы отобрали, полный список есть в вики. Команда Tarantool русскоязычная и все возникшие вопросы по задачам можно задать в отдельном чатике.

У pytest хорошая документация, но она не описывает полезные расширения, которых у pytest огромное количество. Вот этот тьюториал хорошо дополняет документацию - https://stribny.name/blog/pytest/

Все первоапрельские шутки, которые видел, были скучными. Кроме этой - RFC 9225: Software Defects Considered Harmful https://www.rfc-editor.org/rfc/rfc9225.html

23 апреля (уже завтра) в Университете Иннополис пройдёт 2-я международная конференция по качеству кода (Conference on Code Quality, ICCQ). Конференция посвящена таким темам как статический анализ, верификация программ, выявление дефектов и поддержка ПО. Трансляция докладов будет доступна бесплатно, для просмотра нужна регистрация (а может и не нужна, трансляция будет на Ютуб канале).

До сих пор в фреймворке Jepsen не было поддержки внедрения сбоев на уровне файловой системы, если не считать полумертвой интеграции с CharybdeFS, которую добавил в Jepsen один из пользователей. Во всяком случае Кайл ни в одном из своих отчётов по тестированию не упоминал про использование сбоев на уровне ФС. Вчера Кайл Кингсбери добавил в Jepsen серию изменения c поддержкой lazyfs, которая реализует сбои такого типа. Причем репозиторий lazyfs по ссылке не доступен и Кайл пока ничего об этом рассказывать не хочет: "Calm dowwwwwwn, this is literally only hours old, already addressed in the commit message, and won't make its way into release for some time.". Судя по коду в коммитах Jepsen lazyfs работает как FUSE файловая система и поддерживает управление с помощью FIFO-канала.

https://github.com/jepsen-io/jepsen/commit/effe3356438f2054294bf4b898fcf69777197f3f

Есть такой формат тестовых отчётов как Test Anything Protocol (TAP). Он существует примерно с 1988 года (на несколько лет старше JUnit) и широко используется в библиотеках для написания тестов.

TAP version 13
1..5
ok - gh-695: avoid overwriting tuple data necessary for smfree()
ok - gh-1185: no crash in matras_touch
ok - gh-1094: box.snapshot() doesn't abort if out of file descriptors
ok - No crash for second snapshot w/o any changes
ok - Snapshot was recreated

Формат описывает спецификация версии 13, её даже пытались стандартизировать в IETF, но дальше обсуждения черновика стандарта дело не пошло. И вот, спустя семь лет, опубликовали новую версию спецификации. В ней авторы решили задокументировать поведение, которое уже реализовано в популярных реализациях TAP, и не описывать то, что нигде не реализовано. Формальная грамматика отчёта поменялась, но, насколько я понял, с сохранением обратной совместимости.

Из нового:

- спецификация теперь описывает наличие пробелов до и после директив SKIP, TODO
- новое ключевое слово Pragma, которое позволяет управлять поведением тестовой библиотеки
- наличие строк, которые не соответствую грамматике TAP, делают весь отчёт невалидным. Раньше, насколько помню, это было на усмотрение тестовой библиотеки.
- вложенные тесты
- закомментированные тесты

http://testanything.org/tap-version-14-specification.html

Контекст: Google запретил российским и белорусским opensource проектам участвовать в Google Summer of Code 2022, как они определяют национальность открытого исходного кода они не пояснили.

Поэтому команда Tarantool открыла набор на студенческую программу для работы над исследовательскими задачами. Старт запланирован на 1 июля. В первую неделю менторы из числа сотрудников Tarantool познакомят участников с проектом и технологиями, а студенты смогут выбрать задачи, с которыми им предстоит работать — средней или повышенной сложности. Полный список задач, отобранных командой Tarantool - https://github.com/tarantool/tarantool/wiki/Tarantool-Summer-of-Code-2022-ideas. Напоминаю, что среди этих задач есть две, непосредственно связанные с тестированием: фаззер для LuaJIT и интеграция Tarantool с SQLancer.

Решать задачи можно в одиночку или в команде. На задачи средней сложности отводится два месяца, на более сложные — четыре. Разобраться с вопросами и трудностями, возникающими в процессе, поможет ментор. После успешного выполнения участники получат вознаграждение: 120 или 240 тысяч рублей, в зависимости от сложности задачи.

Для участия нужно зарегистрироваться, заполнив форму. Список участников будет объявлен в конце июня 2022 года.

Обновлено (03.06.2022): поправил ссылку на форму.

Опубликовали материалы к прошедшей конференции Kernel recipes. Из всех докладов мое внимание привлёк "Test-driven kernel releases" от Guillaume Tucker. Доклад всё на ту же тему, про которую я уже писал - как координировать тестирование Linux ядра в сообществе: кто и какие тесты запускает, как и где публиковать тестовые отчёты, как минимизировать усилия по тестированию ядра. Если RedHat CKI, KernelCI и syzbot я слышал, то про regzbot было интересно узнать. Это такая штука ля отслеживания регрессий при разработке ядра, есть более подробный пост про regzbot. В докладе автор предлагает три RFC: хранение отчётов о результатах тестирования в репозитории с исходным кодом, использование трейлера Test-link для связи с результатами тестов в описании коммитов, хранение тестовых отчётов в Git и привязка их к коммитам. Тезисы доклада и запись.

P.S. Мне кажется идея хранения тестовых отчётов вместе с кодом в Git классная. Всегда можно посмотреть как тот или иной патч был протестирован. Это не сильно нужно когда всё тестирование синхронное с разработкой - получили зеленую галочку в CI и можно мержить, но полезно, когда после мёржа запускаются остальные тесты. Я даже делал поддержку в cgit для тестовых отчётов, но патчи не нашли понимание в глазах ментейнеров cgit :)

Тоже часто такое замечал: "У опытного тестировщика вырабатывается еще такой навык как буфер памяти. Ну у меня во всяком случае он выработался за годы. Часто бывает выполняя какое-то действие, каскад ввода и вывода происходят практически одновременно. И такой буфер в голове помогает по памяти восстанавливать ход событий за секунды до "аварии", даже если раздел программы тебе незнаком."

via

Внезапно pytest не самый крутой раннер для тестов на Питоне. Результаты бенчмарков показывают, что он ощутимо отстает от других раннеров. В том числе от hammett, который частично совместим с pytest. Источник результатов измерений - https://github.com/boxed/test-benchmarks

Два года назад я делал опрос с вопросом нужен ли материал на тему "Как ускорить регресионное тестирование?" и многие проголосовали с ответом "Да". Мы сейчас в Тарантуле оптимизируем общее время тестирования и все свои мысли на эту тему я изложил в статье в блоге.

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

https://bronevichok.ru/posts/regression.html

Результаты сравнения Address Sanitizer, Memory Sanitizer, Valgrind и Intel Inspector по типу выявляемых ошибок - https://github.com/mediakind-video/memory-sanitizer-benchmark/blob/master/docs/analysis.md

Ричард Столлман представил свою новую книгу "GNU C Language Intro and Reference Manual". Книга нацелена на разработчиков, знакомых с принципами программирования на каком-то другом языке и желающих изучить язык Си. Открываем раздел "5.8 Recursive Functions", копируем пример, собираем, запускаем:

$ cat fac.c 
int
factorial(int x)
{
    if (x < 1)
        return 1;
    else
        return (x * factorial (x - 1));
}

int
main() {
    factorial(1000000000);
}
$ gcc fac.c 
$ ./a.out 
Segmentation fault (core dumped)
$

Отличный учебник!

Началась трансляция секции по анализу программ на "Иванниковских чтениях"
https://www.youtube.com/watch?v=L7ZRV2Voee4

Темы докладов:

- Автоматическое тестирование LLVM-программ со сложными входными структурами данных
- Подходы, направленные на повышение эффективности фаззинг-тестирования компонентов защищенной ОС
- Усовершенствованный фаззинг на основе грамматик
- Сильно оптимистичные решения для динамической символьной интерпретации
- Инструмент динамического анализа IoT-систем ELF с поддержкой символьных вычислений
- Обнаружение ошибок взаимоисключающей блокировки в программах на языке С# при помощи методов статического анализа
- Статический анализатор для языков с поддержкой исключений
- Поиск использований освобожденного ресурса в исходном коде на языке C# методами статического анализа
- Повышение точности статического анализа за счет учета значений полей класса, имеющих единственное константное значение
- Обзор методов статического анализа для поиска утечек памяти
- Генерация шаблонов исправлений кода на основе репозиториев
- Большие трансформеры для генерации кода
- Применение статического анализа исходного кода для поиска проблем с производительностью: примеры из практики
- Построение распределения данных и генерация кода при распараллеливании на гетерогенный вычислительный кластер
- Автоматизация создания окружения при динамическом анализе ПО на основе полносистемного анализа с использованием QEMU

Текущий статус библиотеки libFuzzer:

> The original authors of libFuzzer have stopped active work on it and switched to working on another fuzzing engine, Centipede. LibFuzzer is still fully supported in a sence that important bugs will get fixed. However please do not expect major new features or code reviews, other than for bug fixes.

https://github.com/google/centipede

Помимо активного развития тулинга для фаззинга развивается и тулинг для автоматической генерации целей для фаззинга. Некоторые из них: Futag (C/C++), Hypothesis Ghostwriter (Python), hypothesis-auto (Python), Jazzer (Java). И похоже ещё одним подобным проектом стало больше. Zac Hatfield-Dodds, один из основных разработчиков Hypothesis, разрабатывал платный сервис для тестирования Python-проектов на основе Hypothesis - hypofuzz.com. Судя по всему он решил опубликовать код, который составляет основу этого сервиса. hypofuzz реализован как расширение для hypothesis, использует существующие тесты в проекте для генерации фаззинг целей, процесс фаззинга можно мониторить с помощью веб-интерфейса. Наверное самый простой способ попробовать hypofuzz это запустить его на своих же тестах, потому что нескольких самых популярных модулях для Питона у меня hypofuzz не заработал по тем или иным причинам. Вообщем идея за hypofuzz классная, надеюсь Zac не забросит проект, в документации есть план развития на ближайшее время.