- Name: David Carlos de Araújo Silva
- email: firstname.lastname@example.org
- blog: http://davidcarlos.github.io/
I’am a student of software engineering at University of Brasilia. I have some contributions in Open Source projects, including python and ruby projects. I also have some experience with deploy tools, as Chef, Vagrant and Docker.
- Open Source Contributions:
- Noosfero: Noosfero is a web platform for social and solidarity economy networks with blog, e-Porfolios, CMS, RSS, thematic discussion, events agenda and collective inteligence for solidarity economy in the same system.
- Radar Parlamentar: Processing legislative votes
- GHI: GitHub Issues on the command line.
- Firehose: Interchange format for results for static analysis tools
- I have some experience in RPM packaging, once I had participate in a project on University of Brasilia that used Centos and Fedora as server infrastructure. The repository of the project can be checked here https://gitlab.com/softwarepublico/softwarepublico/tree/master/src. This is important because all the code that we releases to the proposed system, will be packed to RPM, following the rules and the packaging politics of Fedora community.
Why i choose Fedora?
- Fedora is a great open source project, and in the past i had already work with rpm packaging to Fedora and Centos, in a project in University of Brasilia. Work in a GSOC project with the Fedora community is a great oportunity to learn more about it infraestructure, and to deal with rpm packages. I had the desire to realy contribute with distributions that use the rpm package format, and Fedora was my primary choice.
Why this project?
Linux Distributions, as Fedora, continuously releases new versions of packages to your final users. As a user, i want that these packages works fine and not crashes my system. In other words, i want that this package be secure to use. From the point of view of a package maintainer, i also want to my package be secure, but if the code of this package has flaws and bugs, the security and the quality of the package will be compromised. Build a infrastructure that a Linux distribution can continuously extract quality information about the packages that are released to the users, could give to packages maintainers, indicators about the quality of the upstream code, leading to a better strategy to fixing bugs in the package. This continuously process of static analysis will benefit the packages maintainer and the final user, once the package could receive more security fixes, based on the static analysis tools report. Athos Ribiero (athoscr), had proposed an system to rank alarms generated by static analysis tools. We had made contact already, and my intend is to work with him, in order to at least build this system that will collect the static analysis data.
I’m working in the past few months in Debile, a tool created by the Debian community to make static analysis on Debian packages. Make this tool more generic will permit to analyses others fonts of source code, for example Fedora packages. I am also contributing to Firehose project, that parse the output of static analysis tools. These parsers convert the results into a common data model of Python objects, with methods for lossless roundtrips through a provided XML format. Firehose will be necessary to unify the output of the tools that we will use. The final objective that i want to reach, is a system that can monitors repositories, and run the analysis in the new released packages. The result of this analysis will be saved in a database, that can be used to different contexts, including rank the alarms by it's priority.
Why Fedora community should choose me
- In the past two years i'm contributing to some Free Software projects, including Debian. I have a lot of interest in Linux distributions, static analysis and distributed systems.
- My final work in the University, to get my degree, is related to create a infrastructure to collect static analysis with different tools. I'm already using Firehose and Debile projects in this analysis, and as primary result i had generated some XML reports, using Flawfinder, Cppcheck, and a simple plugin that a wrote to Debile. You can check this here https://github.com/tcc-unb-fga/debile.
- In the end of the GSOC, i want to reach the following system architecture:
- Interaction with Fedora community: Make the first interaction with the Fedora community, including the mentor of the project.
- Generalize Debile processor component: This milestone will make Debile processor component more generic, and remove the the coupling with Debian infrastructure.
- Generalize Debile management component: This milestone will make Debile management component more generic, and remove the The coupling with Debian infrastructure. This will permit to create Jobs that not necessarily represents Debian packages.
- Validate new generalized components: This milestone will verify if the new Debile components will be able to work together properly.
- Implement Monitor component: This milestone will implement the component that will check for new packages, and send then to Debile manager component.
- Integrate Monitor and Debile management component: This milestone will implement the integration between the Monitor component and the manager component.
- Run analyses with Debile processor component: This milestone will permit that the Debile processor can run the static analysis tools on the available source code.
- Generate Firehose reports: This milestone will generate the reports using Firehose. I had made two pull requests to Firehose, in order to add one new parser to Flawfinder tool, and other to enable add multiple CWE identifiers in the final report. Only some tools include in their report CWE identifiers, Flawfinder is one of this tools (Cppcheck includes too).
- Save Firehose reports into a database: This milestone will save the Firehose reports in a SQL database.
- My plan is to work full time during the program period.
|Interaction with Fedora community||May 30|
|Generalize Debile processor component||Jun 30|
|Generalize Debile management component||Jun 30|
|Validate new generalized components||Jun 28|
|Run analyses with new Debile processor component||Jun 28|
|Generate Firehose reports||Jun 28|
|Implement Monitor component||August 21 - 29|
|Integrate Monitor and new Debile management component||August 21 - 29|
|Save Firehose reports into a database||August 21 - 29|