This is my membership request to the Ubuntu Security group. Below I detail my contributions to the Ubuntu community and other relevant information.
Verified Identity
As a Canonical employee (and hence member of ~canonical-security) my identity has been verified in person, through legal documents and a background check during my onboarding.
Ubuntu CVE Tracker
As part of publishing USNs I have made merge requests in the Ubuntu CVE Tracker including the following changes to the listed package CVE files:
When patching a CVE, testing is required to ensure no regressions have been introduced.
I’ve written and merged QA regression scripts to both ensure CVEs have been patched correctly and that no regressions have been introduced by a security fix. Furthermore I’ve added testing notes for packages that are tested manually. This includes the following:
+1 from me for @bruce-cable to join ~ubuntu-security - as per [spec] ~ubuntu-security membership he clearly meets all the respective criteria and has contributed significantly to the security of Ubuntu during his time in the ~ubuntu-security-apprentices team.
As presented in the application above, @bruce-cable has clearly met each requirement to join ~ubuntu-security and has done some excellent work with each contribution. +1 from me!
+1 from me as well to support @bruce-cable application to join ~ubuntu-security. The evidence he is providing demonstrates he is meeting the expected criteria. Thanks @bruce-cable for the excellent work!
Hey @bruce-cable this is a great body of work, and I am tentatively a +1 on your lp:~ubuntu-security membership, but could I ask you to describe some of the challenges or quirks that you hit while doing some of the updates?
SInce this process is new, for candidates in general, I think it’s helpful to describe some of the different things they seen (native packages or different source formats, debugging steps taken, etc.) so we can get a picture of what out-of-the-ordinary things you’ve seen. Thanks!
Some of the unusual things I’ve come recently across include:
- Build tests failing for libarchive because access time was not enabled in the fstab for my schroots
- A package with suffix "~rc1" seemingly trumping the non-rc version in LP (Turned out an older version had been deleted)
- A package failing to build because the "single-debian-patch" option was set and my patches weren't applied in the correct order (I updated our tooling to indicate this is set for future builds)
- During my testing of KRB5 some tests were failing due to which ciphers had been enabled, this required debugging to find the cause.