firehose

"Firehose" é um pacote Python destinado a gerenciar os resultados das ferramentas de análise de código (por exemplo, avisos do compilador, análise estática, linters, etc.).

Atualmente, ele fornece analisadores para a saída de GCC, Clang-Analyzer, CPPcheck e FindBugs. Esses analisadores convertem os resultados em um modelo de dados comum de objetos Python, com métodos para ida e volta sem perdas através de um formato XML fornecido. Há também um equivalente a JSON.

Está disponível no Pypi aqui:

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

e via git de:

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

A lista de discussão é:

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

A documentação pode ser lida aqui:

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

O Firehose é um software livre, licenciado no LGPLV2.1 ou (por sua opção) em qualquer versão posterior.

Requer Python 2.7 ou 3.2 em diante e foi testado com sucesso com Pypy.

Atualmente, é de qualidade alfa.

Os formatos de API e serialização ainda não estão estabelecidos em pedra (e estamos interessados ​​em ouvir feedback antes de prender mais as coisas).

Motivação: http://lists.fedoraproject.org/pipermail/devel/2012-dcember/175232.html

Quero matar os resultados da análise de código estático em um banco de dados, o que significa coagir todos os resultados em algum formato comum de intercâmbio, codinome "Firehose" (que também pode ser o nome do banco de dados).

A idéia é um formato XML comum de que todas as ferramentas podem emitir que:

• descreve um aviso
• Fornece a localização do código de origem do aviso: nome do arquivo, função, número da linha.
• Opcionalmente com um identificador CWE
• Potencialmente com outros IDs e URLs, por exemplo, o ID "Sig30-C" com URL https://www.securecoding.cert.org/confluence/display/seccode/sig30-c.+call+only+synchronsous-safel+functionslost
• Opcionalmente, descreve o caminho do código para chegar lá (potencialmente interprocedural entre os arquivos de origem), potencialmente com anotações "estaduais" (por exemplo, no caso de um bug de contagem de referência, é útil poder anotar as alterações no RefCount).

Juntamente com uma API simples do Python para trabalhar com o formato como uma coleção de objetos Python (criando, escreva para XML, lida a partir de XML, modificação, etc.)

Inicialmente, considerei o uso do JSON, mas fui com XML porque, se várias ferramentas vão emitir isso, é bom poder validar as coisas contra um esquema (consulte Firehose.rng, um esquema relax-ng).

As referências a arquivos de origem no formato podem incluir um hash do próprio arquivo de origem (por exemplo, sha-1), para que você possa identificar de maneira única qual arquivo de origem estava falando.

Este formato seria levado no banco de dados para a interface da usuário da web e pode fazer outras coisas sem precisar de um servidor: por exemplo:

• Converta -o na forma textual de um erro de compilação do GCC, para que o emacs etc possa analisá -lo e levá -lo à fonte
• ser transformado em um relatório simples HTML localmente em sua estação de trabalho

Projetos usando Firehose:

• A análise simulada pode reconstruir um RPM de origem, capturando os resultados de 4 ferramentas diferentes de análise de código no formato da case de fogo (juntamente com todos os arquivos de origem mencionados em qualquer relatório).
• O ramo "Fire Hose" de CpyChecker pode emitir nativamente relatórios de Firehose XML
• https://github.com/paultag/storz/blob/master/wrappers/storz-lintian