From Fedora Project Wiki

Contact Information

About Me

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.

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:

Schedule

  • 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.
Milestone Deadline
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
Retrieved from "https://fedoraproject.org/w/index.php?title=GSOC_2017/Student_Application_davidcarlos&oldid=490167"