firehose

"Firehose" est un package Python destiné à gérer les résultats des outils d'analyse de code (par exemple, les avertissements du compilateur, l'analyse statique, les liners, etc.).

Il fournit actuellement des analyseurs pour la sortie de GCC, Clang-Analyzer, CPPCheck et Findbugs. Ces analyseurs convertissent les résultats en un modèle de données commun des objets Python, avec des méthodes detille sans perte via un format XML fourni. Il y a aussi un équivalent JSON.

Il est disponible sur PYPI ici:

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

Et via Git de:

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

La liste de diffusion est:

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

La documentation peut être lue ici:

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

Firehose est un logiciel libre, sous licence dans le LGPLV2.1 ou (à votre option) toute version ultérieure.

Il nécessite Python 2.7 ou 3.2 et a été testé avec succès avec PYPY.

Il est actuellement de qualité alpha.

L'API et les formats de sérialisation ne sont pas encore placés dans la pierre (et nous avons envie d'entendre les commentaires avant de verrouiller davantage les choses).

Motivation: http://lists.fedoraproject.org/pipermail/devel/2012-dembember/175232.html

Je veux faire avancer les résultats de l'analyse de code statique dans une base de données, ce qui signifie contraindre tous les résultats dans un format d'échange commun, nommé "Firehose" (qui pourrait également être le nom de la base de données).

L'idée est un format XML commun que tous les outils peuvent émettre:

• décrit un avertissement
• donne l'emplacement du code source de l'avertissement: nom de fichier, fonction, numéro de ligne.
• éventuellement avec un identifiant CWE
• Potentiellement avec d'autres ID et URL, par exemple l'ID "SIG30-C" avec URL https://www.securecoding.cert.org/confluence/display/seccode/Sig30-C.+Call+Only+Asynchronous-Safe+Functions+within+Sigal+Handlers
• décrit éventuellement le chemin de code pour y arriver (potentiellement interprocédural sur les fichiers source), potentiellement avec des annotations "d'état" (par exemple dans le cas d'un bogue de comptage de référence, il est utile de pouvoir annotter les modifications apportées au refroidissement).

Avec une simple API Python pour travailler avec le format comme une collection d'objets Python (créer, écrire à XML, lire à partir de XML, modification, etc.)

J'ai d'abord envisagé d'utiliser JSON, mais je suis allé avec XML parce que si plusieurs outils vont émettre cela, il est bon de pouvoir valider des choses contre un schéma (voir Firehose.rng, un schéma de relax-ng).

Les références aux fichiers source dans le format peuvent inclure un hachage du fichier source lui-même (par exemple SHA-1) afin que vous puissiez identifier de manière unique le fichier source dont vous parliez.

Ce format serait interrompu dans la base de données pour l'interface utilisateur Web et pourrait y avoir d'autres choses sans avoir besoin d'un serveur: par exemple:

• Convertissez-le en la forme textuelle d'une erreur de compilation GCC, afin qu'Emacs, etc. puisse l'analyser et vous emmener à la source
• être transformé en un simple rapport HTML localement sur votre poste de travail

Projets utilisant Firehose:

• La maquette avec l'analyse peut reconstruire un régime source, capturant les résultats de 4 outils d'analyse de code différents au format Firehose (ainsi que tous les fichiers source qui ont été mentionnés dans n'importe quel rapport).
• La branche "Firehose" de CPYChecker peut émettre des rapports XML de Firehose XML
• https://github.com/paultag/storz/blob/master/wrappers/storz-lintian