Протестировал @sqaunderhood Channel on Telegram

Протестировал

@sqaunderhood


Рекламу и анонсы не размещаю.

Авторский канал о качественной разработке ПО (процессы, тестирование, формальная верификация и спецификация).

— Дзен https://dzen.ru/sqaunderhood
— VK https://vk.com/sqaunderhood
— Твиттер https://twitter.com/sqaunderhood

Протестировал (Russian)

Если вы интересуетесь качественной разработкой программного обеспечения, то канал "Протестировал" от пользователя sqaunderhood - это то, что вам нужно! Здесь вы не найдете рекламы и анонсов, только информацию о процессах разработки, тестировании, формальной верификации и спецификации программного обеспечения. Авторский контент, представленный в этом канале, поможет вам расширить свои знания в данной области и быть в курсе последних тенденций. Не упустите возможность подписаться и быть в курсе всех обновлений! Посетите также Дзен, ВК и Твиттер sqaunderhood для дополнительной информации.

Протестировал

16 Nov, 09:03


Доклад "What's Still Missing in Static Analysis? A Decade-Long Journey." c Симпозиума по статическому анализу (SAS 2024), который описывает последние достижения в использовании машинного обучения в выявлении уязвимостей с помощью стат. анализа:

"The field of static analysis has made enormous progress over the past few decades. Static analysis tools are now routinely used to improve software quality in industry. Static analysis frameworks like CodeQL have helped discover hundreds of security vulnerabilities and seek to democratize the technology by enabling developers to write custom queries. Despite these advances, static analysis faces challenges that greatly limit its effectiveness and accessibility in practice. In this talk, I will show how ideas from machine learning can help alleviate them, most notably in inferring specifications. I will cover a wide range of approaches that trace the arc of the field of machine learning itself, starting from probabilistic graphical models like Markov Logic Networks and Bayesian Networks, to deep learning models like Graph Neural Networks and Transformers, and ultimately modern approaches involving Large Language Models and compound AI systems including neurosymbolic and agent frameworks."

Слайды: https://docs.google.com/presentation/d/1ZbgfX2qJNdeScuSY75M27OHuzQ0Atkaz3-mSH7-nn_4/mobilepresent#slide=id.g19367960644_1_206
Видео: https://www.youtube.com/watch?v=yOzqdhYouUU&t=2425s

Протестировал

31 Oct, 11:03


Лесли Лампорт опубликовал новый черновик своей книги "A Science of Concurrent Programs":

> The book explains the scientific principles underlying the TLA+ language. It contains a lot of math. All the math beyond high school algebra is explained, but it will be tough going for readers who haven't taken an introductory university math class for computer science students that covers things like sets and logic. The book contains little discussion of how TLA+ is used in practice, but it explains why TLA+ is what it is.

Если первая книга про TLA+ "Specifying systems" ориентирована на пользователей, то "A Science of Concurrent Programs" ориентирована на тех, кто хочет разобраться в теории, на которой зиждется TLA+.

https://lamport.azurewebsites.net/tla/science-book.html

Протестировал

16 Oct, 15:14


К затравке доклада у меня даже есть пример из нашей практики фаззинга LuaJIT: мы давно фаззим LuaJIT, полного покрытия не достигли, но нашли полтора десятков крешей в нем. И пока мы делали фаззеры, которые по грамматике генерировали входные данные, пришел какой-то парень в тикетницу LuaJIT и принес пачку крешей, репро которых выглядело как абсолютно мусорные данные. Какая здесь мораль? Не знаю, наверное то, что иногда умничать вредно.

Протестировал

15 Oct, 11:32


Любопытный доклад вышел в видео-подкасте OffByOne Security в прошлую субботу, 14 сентября 2024 г. - "Fuzzing from First Principles" (cлайды, видео, конспект дискуссии) за авторством Алисы Esage Шевченко.

Затравка у доклада следующая:

Гугл со своими фаззинг-движками, обертками для большого количества опенсорс проектов и десятками тысяч машин постоянно фаззит эти проекты и тем не менее в них находят уязвимости (как примеры проектов: 0-day в v8 и Chrome), которые находят тоже с помощью фаззинга. Как так?

"Ex. You spent three months writing a custom coverage-guided fuzzer and it didn’t find any bugs in time budget. Meanwhile, your friend wrote a “dumb” specialized fuzzer in a day and found a bug to win the contest in an hour. Who fuzzed smarter?"

Далее короткий конспект доклада от Алисы:

"В своей модели я рассматриваю два экстремальных уровня приложения теорвера к фаззингу. На низком уровне - это оценка вероятностей прохождения фаззером конкретных условных развилок в коде программы. На высоком уровне - интерпретация фаззера, программы, и ее уязвимостей как распределения вероятностей входных данных, которые они генерируют/принимают. Основное предназначение модели - направлять исследовния в области практических улучшений фаззинга. Привожу простые и наглядные примеры того, как это работает, из своих исследовательских проектов за последние 10 лет. Модель также применима к аналитическим задачам.

Анализ прикладных техник фаззинга через перспективу данной теоретической модели позволяет вскрыть неудобную правду, которую фаззинг комьюнити "заметает под ковер": чистая эффективность фаззинга составляет не более 1%, этот показатель падает в глубину программы, разработчики ЭТО масштабируют на вычислительные облака и называют "умным фаззингом". Я считаю, что масштабирование разумно, когда оно приумножает эффективный и продуктивный процесс - но масштабирование прогрессивно убыточного процесса?! Бесспорно, данный подход позволяет найти больше уязвмостей за единицу времени, при этом по сути он умножает непродуктивность. Фаззинг, который преимущественно жжет электричество и портит климат - это не умный фаззинг, это сумасшествие в погоне за выгодой. Мы можем лучше, да?

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

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

Протестировал

10 Oct, 19:17


Насчёт "customers’ creativity" верно подмечено, креативность зачастую безграничная.

"We continually prioritize which features to implement and bugs to fix based on customer impact. Those actions generate more tests, but our set of tests remains finite whereas our customers’ creativity is infinite."

via

Протестировал

09 Oct, 11:03


Контест VeHa, в рамках которого состоятся соревнования по верификации моделей и дедуктивной верификации, пройдет в этом году с 18 по 21 октября оффлайн в Иннополисе и онлайн. Планируемые задачи уже опубликованы на сайте контеста.

Протестировал

04 Oct, 12:10


Пятничное.

I was interviewing a woman for a QA position, and asked her why she liked QA. She said: "Where else can you get paid to complain?".

via

Протестировал

29 Sep, 20:17


В своем докладе я ссылался на проект Alive2, который позволяет с помощью SMT проверять эквивалентность LLVM IR. Для GCC есть похожий проект - smtgcc, который представляет собой расширение для верификации оптимизаций в GCC, по аналогии с LLVM IR используется внутренее представление компилятора - GIMPLE IR. В списке трофеев 26 проблем в GCC. На ежегодной конференции GNU Cauldron автор проекта Krister Walfridsson сделал доклад про smtgcc.

https://www.youtube.com/watch?v=vrkR7jKcFpw

Добавлено (07.10.2024): Слайды https://gcc.gnu.org/wiki/cauldron2024.

Протестировал

03 Jun, 20:06


GWPSan: Sampling-Based Sanitizer Framework

GWPSan is a framework for low-overhead sampling-based dynamic binary instrumentation, designed for implementing various bug detectors (also called "sanitizers") suitable for production uses. GWPSan does not modify the executed code, but instead performs dynamic analysis from signal handlers.

> Note: GWPSan is inspired by GWP-ASan, but their design and implementation are completely different.

https://github.com/google/gwpsan

Протестировал

17 May, 13:12


Kyle Kingsbury (aphyr) опубликовал отчёт о тестировании БД Datomic Pro. Сам отчёт как всегда интересный, не буду его пересказывать, почитайте сами по ссылке.

Мне показалась забавной одна деталь. Работа над этим отчётом была проспонсирована банком NuBank, очевидно потому что они используют Datomic и заинтересованы в надёжности Datomic. В отчёте Кайл, как обычно, рассказывает какие тесты использовали и для Datomic это были List Append, List Append with CaS, Internal (вариация List Append) и тест Grant. И забавно то, что команда Jepsen тестировала СУБД по запросу банка, но не использовала в тестировании популярный тест bank, в котором создаются счета, в процессе тестирования переводятся деньги между счетами и при успешном исходе общая сумма на счетах не должна измениться.

via

Протестировал

17 May, 12:29


Запись доклада https://www.youtube.com/watch?v=aEiO-nyppmE

Протестировал

17 May, 08:13


Получилось много слов и наверное надо написать выводы:

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

Протестировал

17 May, 08:13


История (не)успеха

Есть такой проект FreeRDP, в рамках которого разрабатывается библиотека для работы по протоколу RDP (Remote Desktop Protocol). Я когда-то давно делал несколько патчей для FreeRDP и их приняли в основную ветку, так что проект не был мне совсем чужим. Позднее я решил нанести ещё немного пользы проекту и интегрировать его в OSS Fuzz, чтобы фаззинг-тесты помогли разработчикам сделать код библиотеки более надежным. Помимо моего желания была ещё одна причина - периодически в библиотеке находили CVE и один из докладов на BlackHat был целиком посвящен "дырявости" FreeRDP - "Fuzzing and Exploiting Virtual Channels in Microsoft Remote Desktop Protocol for Fun and Profit". Чтобы сделать интеграцию проекта в OSS Fuzz надо сделать как минимум три вещи: добавить хотя бы один фаззинг тест в проект, сделать статическую сборку фаззинг-тестов в проекте и добавить сборочные скрипты в репозиторий OSS Fuzz.

Итак, в феврале 2020 году я выбрал для фаззинг-тестов самые простые цели в FreeRDP - небольшие модули, которые уже были покрыты юнит-тестами, и сделал для них обёртки для LibFuzzer. Всё это я делал в свободное время и задачка немного растянулась во времени, первые патчи с тестами смержили только через год - в декабре 2020. Следом за тестами добавил в проект отдельную CMake-опцию для включения сборки фаззинг-тестов. Нужно отдать должное ментейнерам проекта - ревью моих патчей почти всегда было оперативным.

Тесты были добавлены в проект и я сделал патч для OSS Fuzz. В теории работа это несложная: выбрать CMake-опции, с которыми собирать проект, чтобы не собрать лишнее, убедиться, что тесты собираются статически, есть аппрув от ментейнеров проекта и это наверное всё. На первом запуске CI для моего патча случилось страшное:

clang-15: error: unable to execute command: Segmentation fault (core dumped)


Хм, но Clang это не какой-то местечковый проект, почему он сегфолтит? Пока я думал и пытался отладить проблему мой PR закрыл один из ментейнеров OSS Fuzz, потому что "I was cleaning out some old issues/PRs, didn't realise this one was still active.". Я перестал проявлять активность в PR и его хотели прикрыть.

Пока идей с фиксом проблемы для Clang не было я сделал патч для статической сборки FreeRDP. Его закатали в основную ветку супер быстро - за 8 дней.

Проблема с Clang не решена. Тем временем код фаззинг-тестов собирается только под отдельной опцией в FreeRDP и может начать протухать - в одном из патчей переделали API и один из тестов сломался. Поэтому сделал отдельный воркфлоу в CI FreeRDP, чтобы собирать фаззинг-тесты на каждый коммит и проверять, что они не сломаны. Патч залили за 1 день.

Прошло 3 года. Я попробовал убрать опцию для LTO в FreeRDP и Clang перестал сегфолтить. Патч для интеграции FreeRDP наконец-то залили в OSS Fuzz.

Год 2023. Тесты запускаются в OSS Fuzz, всё работает. Потом сборка тестов в OSS Fuzz внезапно ломается. Нахожу коммит в FreeRDP, который сломал сборку. В переписке с ментейнером FreeRDP я пытаюсь аккуратно узнать почему на "красный" CI залили патч. Проблема в том, что все зависимости FreeRDP для сборки фаззинг-тестов описаны в репозитории OSS Fuzz, а разработчики не могут сами делать патчи для OSS Fuzz и при добавлении новых зависимостей всё ломается. Потом ещё раза два так сборка ломалась и я перестал уже обращать внимание на письма от OSS Fuzz про сломанную сборку. А разработчики FreeRDP и вовсе отключили в CI фаззинг.

Весной 2024 ментейнер FreeRDP делает патч, который переносит сборочные скрипты из репозитория OSS Fuzz в репозиторий FreeRDP. Сборка работает.

В апреле 2024 сотрудник Kaspersky сделал фаззинг-тест, который нашел несколько уязвимостей (Integer overflow & OutOfBound Write) в коде FreeRDP.

Ментейнеры в оперативном порядке исправляют уязвимости и выпускают новую версию с исправлениями:

https://github.com/FreeRDP/FreeRDP/releases/tag/2.11.6
https://github.com/FreeRDP/FreeRDP/security/advisories/GHSA-q5h8-7j42-j4r9

Протестировал

26 Apr, 16:04


> Microsoft и IBM открыли код операционной системы MS-DOS 4.0

В опубликованном коде ни одного теста. Где тесты, Зин?

Протестировал

09 Apr, 15:41


GCC 14 умеет рисовать ASCII-диаграммы для визуализации проблем с переполнением буфера.

via

Протестировал

04 Apr, 19:08


Видео доклада How Badly Do We Want Correct Compilers? (NDC TechTown 2023)

Доклад известного исследователя Джона Регира (John Regehr). Докладчик, насколько можно заметить, ни разу не произносит слово "CompCert" и сомневается в успешности проектов формально верифицированных компиляторов для популярных ЯП, что, конечно, интригует. Рассматриваются инструменты, в разработке которых принял участие автор доклада: YARPGen, Souper и другие проекты.

via

Протестировал

04 Apr, 19:06


ChatGPT использует материалы из моей вики про тестирование.

Протестировал

25 Mar, 11:35


Из интересного в результатах ежегодного опроса среди разработчиков от JetBrains за 2023 год:

8% респондентов используют мутационное тестирование как одну из техник тест-дизайна,
а техникой "угадывание ошибок" пользуются 16%.

Больше половины опрашиваемых так или иначе использовали искусственный интеллект для генерирования тестов.
Более 80% хотели бы использовать AI для написания тестов, а 18% хотели бы продолжить это самостоятельно.

via Developer Ecosystem и Developer Ecosystem (Testing)

См. результаты опросов за прошлые года: 2019, 2020, 2021.

Протестировал

16 Mar, 09:41


Расширение для визуализации тестирования кода на Python с помощью Hypothesis в VScode.

https://marketplace.visualstudio.com/items?itemName=HarrisonGoldstein.tyche