firehose

"Firehose" ist ein Python -Paket, das für die Verwaltung der Ergebnisse aus Codeanalyse -Tools (z. B. Compiler -Warnungen, statische Analyse, Linter usw.) bestimmt ist.

Derzeit liefert es Parser für die Ausgabe von GCC, Clang-Analyzer, CPPcheck und Findbugs. Diese Parser wandeln die Ergebnisse in ein gemeinsames Datenmodell von Python -Objekten um, mit Methoden für verlustlose Roundtrips durch ein bereitgestelltes XML -Format. Es gibt auch ein JSON -Äquivalent.

Es ist hier auf PYPI erhältlich:

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

und über Git von:

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

Die Mailingliste lautet:

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

Dokumentation kann hier gelesen werden:

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

Firehose ist kostenlose Software, lizenziert unter der späteren Version LGPLV2.1 oder (nach Ihrer Option).

Es erfordert ab Python 2.7 oder 3.2 und wurde erfolgreich mit Pypy getestet.

Es ist derzeit von Alpha -Qualität.

Die API- und Serialisierungsformate sind noch nicht in Stein gemeißelt (und wir sind bestrebt, Feedback zu hören, bevor wir die Dinge mehr einsperren).

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

Ich möchte die Ergebnisse aus der statischen Codeanalyse in eine Datenbank schlucken, was bedeutet, dass alle Ergebnisse in ein gemeinsames Austauschformat, den Codenamen "Firehose", umgezwungen werden (was auch der Name der Datenbank sein könnte).

Die Idee ist ein übliches XML -Format, das alle Werkzeuge ausgeben können:

• beschreibt eine Warnung
• Gibt den Standort der Quellcode der Warnung an: Dateiname, Funktion, Zeilennummer.
• Optional mit einem CWE -Kennung
• Potenziell mit anderen IDs und URLs, z. B. der ID "Sig30-C" mit URL https://www.securecoding.cert.org/confluence/display/seccode/sig30-c.+call+only+Asynchronous-safe+ -Within+ -Signal+ -Anthandlers-Handlungshandlers+ Handlers-Handlers-Signal+-Hand- und Handlungshandlern-Hand- und Handlungs- und Handlungs- und Handlungs- und Handlungs- und Handlungs- und Handlungs- und Handlungs- und Handlungs- und Hand- und Handligungsfunktionen ---Withins-Withins-Withinals-Hand- und Handligersemperaturen-Handlungshandel-Handligern.
• beschreibt optional den Codepfad, um dorthin zu gelangen (potenziell interproceduralübergreifend zwischen Quelldateien), möglicherweise mit "Status" Anmerkungen (z.

Zusammen mit einer einfachen Python -API für die Arbeit mit dem Format als Sammlung von Python -Objekten (Erstellen, Schreiben in XML, Lesen Sie aus XML, Modifikation usw.)

Ich habe zunächst überlegt, JSON zu verwenden, ging aber mit XML, denn wenn mehrere Tools dies ausgeben wollen, ist es gut, Dinge gegen ein Schema zu validieren (siehe Firehose.rng, ein Relax-NG-Schema).

Verweise auf Quelldateien im Format können einen Hash der Quelldatei selbst (z. B. SHA-1) enthalten, damit Sie eindeutig identifizieren können, über welche Quelldatei Sie gesprochen haben.

Dieses Format würde für die Web -Benutzeroberfläche in die DB geschlüpft und kann andere Dinge tun, ohne einen Server zu benötigen: z. B.:

• Konvertieren Sie es in die Textform eines GCC -Kompilierungsfehlers, damit EMACs usw. sie analysieren und zur Quelle bringen können
• in einen einfachen HTML -Bericht vor Ort auf Ihrer Workstation verwandelt werden

Projekte mit Firehose:

• Die Mock-with-Analyse kann ein Quell-Drehzahl wieder aufbauen und die Ergebnisse von 4 verschiedenen Codeanalyse-Tools im Firehose-Format erfassen (zusammen mit allen in jedem Bericht erwähnten Quelldateien).
• Der "Firehose" -Ast von CPyChecker kann Firehose XML -Berichte nativ ausgeben
• https://github.com/paultag/storz/blob/master/wappers/storz-lintian