Gentoo-GPG: Final Report

Hello,

This is the last week of the Gentoo-GPG Google Summer of Code project. It has been a fun ride where I learned a whole lot of things from little Python tricks to how Portage verifies GnuPG signatures. It will be an unforgettable experience that has helped me make an entrance to the open source community and shown me the success and the difficulties that can be found there. Now, for the summary of the work that I have done, I have written it below in two segments, Gentoo-Keys and MetaManifest.

Gentoo-Keys

In my proposal which can be found here, I promised to deliver on many things, most which I was able to achieve, while, in the end, one thing I and my mentors decided not to prioritize for that time frame, which I replaced with deliverables outside the proposal. More specifically, due to the complexity of pyGPG and Gentoo-Keys, I was unable to make unit tests for Gkeys because of time constraints. In return, I spent more time working the email reminder generator and fixing older Gkeys functions. All the other deliverables were accomplished. A combined PR of all my Gkeys code can be found in the branch here.

  1. Count Incorrect Qualified IDs and present them in the Spec Check summary.  (link) (done in the bonding period)
  2. Added a requirements file that includes required packages for Gkeys to run. (link) (done in the 1st week)
  3. Fixed the move-seed function that was broken due to more recent patches. (link) (done in the 1st week)
  4. Created the update key function that downloads and installs the seeds of a selected Gkeys category or all categories. (link) (done in the 2nd and 3rd week)
  5. Add automatic update seed check whenever Gkeys runs, that checks if the seeds match with the ones from the server and if not, it gives the user the option to use update-seed. (link same PR as above) (done in the 4th week and 5th week)
  6. Made the default GPG config file over-ridable in Gkeys-Gen during the generation of a new key. (link) (done in the 4th week)
  7. Fixed a small bug in the verify function of Gkeys. (link) (done in the 4th week)
  8. Created the send-key function (dubbed upload key in the proposal) that send the selected key/s in the selected server of the config file. In order to get that to work though, I had to make a small patch in pyGPG as well. (link, link) (done in the 5th week)
  9. Created an email reminder generation script that works along with spec-check and using the Spec Check tuple, checks if a key has expired or is expiring in a selected time frame from the config file and if it is, it sends an email to the key’s owner that includes all the information needed along with resources on how to update the key. It priorities emails with a preferred address found in the config file and has the option to login in either email account found again in the config file. (link) (done in the 10th and 11th week)

Meta Manifest System

In my proposal, I also promised to implement the new Meta Manifest system according to GLEP:58 which is a system that provides a more efficient way to verify the integrity of Gentoo distribution. It works is by creating many different Manifest files for all important directories of a tree (ex. categories, profiles etc.) and then adding the hash sums of those Manifest files to create a master Meta Manifest file in the root directory, which is afterwards GPG signed by an official Gentoo key. That way, the user only needs to verify the master meta manifest file to check the integrity of the tree, which will automatically go through every single manifest file and verify its hash sum. If a package from a category is fully missing, then it is ignored, since partial downloads of categories are allowed as long as the downloaded packages include everything. Here is the link to the PR. The project was divided in two parts:

  1. The creation and signing  process of the Meta Manifest files by using the logic above. (done in the 6th to 8th week)
  2. The verification and signature validation process of the Meta Manifest files.  (done in the 9th to 11th week)

Plans for the future

My plan for the future is to continue supporting my code for Portage like making minor fixes and reworking some functions from the original manifest code that seem a little inefficient. I would also like to become part of the team developing Gentoo-Keys and prepare for the next release of the platform.

Conclusion

Finally, I would like to thank all those people that helped me with the project. Firstly my mentors, Pavlos ‘dastergon’ Ratis, Brian ‘dol-sen’ Dolbec and Kristian ‘K_F’ Fiskerstrand for their guidance and suggestions, and always being there whenever I had questions. Also, I would like to thank Doug ‘dwfreed’ Freed, Zac ‘zmedico’ Medico and Gilles ‘EvaSDK’ Dartiguelongue for reviewing my code and giving useful tips.

-aeroniero