firehose

"Firehose" es un paquete de Python destinado a administrar los resultados de las herramientas de análisis de código (por ejemplo, advertencias del compilador, análisis estático, revestimientos, etc.).

Actualmente proporciona analizadores para la salida de GCC, Clang-Analyzer, CPPCheck y FindBugs. Estos analizadores convierten los resultados en un modelo de datos comunes de objetos de pitón, con métodos para viajes redondos sin pérdidas a través de un formato XML proporcionado. También hay un equivalente JSON.

Está disponible en Pypi aquí:

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

y a través de Git de:

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

La lista de correo es:

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

La documentación se puede leer aquí:

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

FireHose es un software gratuito, con licencia bajo LGPLV2.1 o (a su opción) cualquier versión posterior.

Requiere Python 2.7 o 3.2 en adelante, y se ha probado con éxito con Pypy.

Actualmente es de calidad alfa.

La API y los formatos de serialización aún no están en piedra (y estamos interesados ​​en escuchar comentarios antes de bloquear más las cosas).

Motivación: http://lists.federaproject.org/pipermail/devel/2012-december/175232.html

Quiero sorber los resultados del análisis de código estático en una base de datos, lo que significa coaccionar todos los resultados en algún formato de intercambio común, con nombre en códigos de incendios "(que también podría ser el nombre de la base de datos).

La idea es un formato XML común que todas las herramientas pueden emitir que:

• describe una advertencia
• Da la ubicación del código de origen de la advertencia: nombre de archivo, función, número de línea.
• Opcionalmente con un identificador CWE
• Potencialmente con otras ID y URL, por ejemplo, la ID "Sig30-C" con URL https://www.securecoding.cert.org/confluence/display/seccode/sig30-c.+call+only+Asynchronous safefe+Functions+Within+signal +handlers
• Opcionalmente, describe la ruta del código para llegar (potencialmente interrupción en todos los archivos de origen), potencialmente con anotaciones de "estado" (por ejemplo, en el caso de un error de conteo de referencia, es útil poder anotar los cambios en la cuenta de la referencia).

Junto con una API de Python simple para trabajar con el formato como una colección de objetos de Python (crear, escribir en XML, leer desde XML, modificación, etc.)

Inicialmente consideré usar JSON, pero fui con XML porque si múltiples herramientas van a emitir esto, es bueno poder validar las cosas contra un esquema (ver FireHose.rng, un esquema relajado-ng).

Las referencias a los archivos de origen en el formato pueden incluir un hash del archivo de origen (por ejemplo, SHA-1) para que pueda identificar de manera única de qué archivo fuente estaba hablando.

Este formato se vería sorbiendo en el DB para la interfaz de usuario web, y puede hacerse otras cosas sin necesidad de un servidor: por ejemplo:

• Conviértalo a la forma textual de un error de compilación GCC, para que las emacs, etc. puedan analizarlo y llevarlo a la fuente
• convertirse en un informe HTML simple localmente en su estación de trabajo

Proyectos utilizando FireHose:

• Mock-with-análisis puede reconstruir una fuente de rpm de origen, capturando los resultados de 4 herramientas de análisis de código diferentes en formato de manguera de fuego (junto con todos los archivos de origen que se mencionaron en cualquier informe).
• La rama "Firehose" de CPyChecker puede emitir de forma nativa los informes de XML de FireHose
• https://github.com/paultag/storz/blob/master/wrappers/storz-lintian