firehose

«Firehose» - это пакет Python, предназначенный для управления результатами инструментов анализа кода (например, предупреждения компилятора, статический анализ, Linters и т. Д.).

В настоящее время он предоставляет анализаторы для вывода GCC, Clang-Analyzer, CPPCHECK и Findbugs. Эти анализаторы преобразуют результаты в общую модель данных объектов Python, с методами без потерь обратно познания через предоставленный формат XML. Есть также эквивалент JSON.

Он доступен на PYPI здесь:

https://pypi.python.org/pypi/firehose

и через git от:

https://github.com/fedora-static-analysis/firehose

Список рассылки:

https://admin.fedoraproject.org/mailman/listinfo/firehose-devel

Документация можно прочитать здесь:

http://firehose.readthedocs.io/en/latest/

Firehose - это свободное программное обеспечение, лицензированное под LGPLV2.1 или (по варианту) любую более позднюю версию.

Это требует Python 2.7 или 3.2 и далее, и был успешно протестирован с помощью PYPY.

В настоящее время он качества альфа.

Форматы API и сериализации еще не зарегистрированы в камне (и мы заинтересованы в обратной связи, прежде чем мы заблокируем вещи больше).

Мотивация: http://lists.fedoraproject.org/pipermail/devel/2012-december/175232.html

Я хочу сократить результаты анализа статического кода в базу данных, что означает принуждение всех результатов в какой -то общий формат обмена, кодовой «пожарный» (что также может быть названием базы данных).

Идея - это обычный формат XML, который могут излучать все инструменты:

• описывает предупреждение
• Дает местоположение исходного кода предупреждения: имя файла, функция, номер строки.
• При желании с идентификатором CWE
• Потенциально с другими идентификаторами и URL, например, идентификатор «sig30-c» с URL https://www.securecoding.cert.org/confluence/display/seccode/sig30-c.+call+only+synchronous-safe+functions+signal+lers.
• При желании описывается путь кода, чтобы добраться туда (потенциально межпроцедурной между исходными файлами), потенциально с аннотациями «состояния» (например, в случае ошибки с подсчета эталона, полезно иметь возможность аннотировать изменения в RefCount).

Вместе с простым Python API для работы с форматом в качестве коллекции объектов Python (создание, записать в XML, прочитать из XML, модификация и т. Д.)

Первоначально я подумал об использовании JSON, но пошел с XML, потому что, если несколько инструментов будут излучать это, хорошо иметь возможность проверять вещи против схемы (см. Firehose.rng, схема расслабления-NG).

Ссылки на исходные файлы в формате могут включать хэш самого исходного файла (например, SHA-1), чтобы вы могли однозначно определить, о каком исходном файле вы говорите.

Этот формат был бы внедрен в БД для веб -интерфейса и может сделать другие вещи, не нуждаясь в сервере: например:

• Преобразовать его в текстовую форму ошибки компиляции GCC, чтобы EMACS и т. Д. Могла проанализировать его и доставить вас к источнику
• быть превращенным в простой HTML -отчет локально на вашей рабочей станции

Проекты с использованием Firehose:

• Измешительный анализ может восстановить RPM-источник, захватывая результаты 4 различных инструментов анализа кода в формате Firehose (наряду со всеми исходными файлами, которые были упомянуты в любом отчете).
• «Пожарная» ветвь CPYCHECKER может изначать отчеты Firehose XML
• https://github.com/paultag/storz/blob/master/wrappers/storz-lintian