[gentoo-soc] Gentoo-GPG: Final Report

[Angel Perivolaropoulos]

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
<https://docs.google.com/document/d/14ZCjQuuoymPBgEEOgCs3Evu44t5ZWxfKSjOdU1AfPcU/edit?usp=sharing>,
I promised to deliver on many things, most which I was able to achieve,
while, in the end, one thing I 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 and was advised not to by my mentors 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 code that has not yet been merged
can be found here <https://github.com/gentoo/gentoo-keys/pull/52>.

   1. Count Incorrect Qualified IDs and present them in the Spec Check
   summary.  (link
   <https://github.com/gentoo/gentoo-keys/commit/bacec7da1e7ff446f232d48dcf34b71966df7068>)
   (done in the bonding period)
   2. Added a requirements file that includes required packages for Gkeys
   to run. (link
   <https://github.com/gentoo/gentoo-keys/commit/0cb7bf0d8e0d4649f48631956eb3e8026b01639f>)
   (done in the 1st week)
   3. Fixed the move-seed function that was broken due to more recent
   patches. (link
   <https://github.com/gentoo/gentoo-keys/commit/423c3bf0b3ae993e15886858aede0a94372b55fd>)
   (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
   <https://github.com/gentoo/gentoo-keys/pull/46>) (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
   <https://github.com/gentoo/gentoo-keys/pull/46>) (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
   <https://github.com/gentoo/gentoo-keys/pull/48>) (done in the 4th week)
   7. Fixed a small bug in the verify function of Gkeys. (link
   <https://github.com/gentoo/gentoo-keys/pull/49>) (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 <https://github.com/gentoo/gentoo-keys/pull/50>, link
   <https://github.com/dol-sen/pyGPG/commit/304a2998b9322dd199adc514c559093300ac7d1f>)
   (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
   <https://github.com/gentoo/gentoo-keys/pull/51>) (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 <https://wiki.gentoo.org/wiki/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 is much more
efficient than checking each manifest file separately. Here
<https://github.com/gentoo/portage/pull/38> 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