Hey Folks,
I’m requesting membership to ~ubuntu-security.
Team membership
Ubuntu Security Apprentices: Joined on 2024-06-24
Canonical Security Team: Joined on 2024-06-24
Canonical: Joined on 2024-06-24
Verified identity
My identity was verified through the general Canonical employee onboarding process, which includes a background check and verification of my government-issued identity documentation.
My PGP signed “Ubuntu Codes of Conduct” is attached to my Launchpad account and available here.
History of high-quality sponsored security updates
I’ve published several high-quality updates, including ‘vendor’ security patches:
- USN-6907-1
- USN-6530-2
- USN-6935-1: patched prometheus-alertmanager, which included vendor security patch for Ubuntu 18.04 as upstream patch was in elm lang whereas prometheus-alertmanager for Ubuntu 18.04 used angular.js.
- USN-7002-1: patched setuptools, which included vendor security patch for Ubuntu 22.04, 20.04, 18.04, 16.04, 14.04 as upstream patch version had dropped support for
svn
whereas these versions still supported it and were vulnerable. - USN-7038-1
- USN-7038-2
- USN-7048-1
- USN-7048-2
- USN-7067-1
- USN-7080-1
- Patching any CVE, I always try to develop a PoC to ensure the package has the expected behaviour after patching. For most of the USNs mentioned above, I have developed a PoC to test the patches.
- Some PoCs are hard to come up with due to limited documentation; for e.g., the squid CVE patch (USN-6907-1) had vulnerable code in Edge Side Includes (ESI) processing, and the PoC was difficult to come up with due to limited resources on the topic.
- Testing setuptools patch (USN-7002-1) was difficult due to a lot of dependency problems as many versions had test dependencies on custom branches that no longer existed, so pinning dependencies with manual verification was required. The older versions of the package did not use
pytest-subprocess
(as it was not available for that version), so the tests had to be rewritten to utilize what was available. - Unbound (USN-7080-1) was using the
single-debian-patch
option, which didn’t allow for straightforward patching of the package. I did some research on the option, and its ideal usage and opened aumt
MR to better handle such packages to improve the process.
Demonstrated understanding of required tools and systems
I have worked with the security patching tooling and have raised the following MRs to improve the process/fix some bugs:
- Merge into master : single-debian-patch-logic-update : lp:~vyomydv/ubuntu-security-tools : Git : Code : ubuntu-security-tools
- Merge into master : fix-lpmad-output-parsing : lp:~vyomydv/ubuntu-security-tools : Git : Code : ubuntu-security-tools
I have also created the required MRs to update the Ubuntu CVE Tracker to incorporate the above-mentioned CVE patches.
Demonstrated responsive and respectful communication
I have signed the code of conduct. I regularly monitor Launchpad bugs for packages I have patched, as well as relevant mailing list announcements, and I am looking for possible regressions. Only once have I received a clarification email for one of my USNs’ wording, which mentioned a crash might not be possible; instead, it would just be a denial of service with the application consuming high memory. However, that is not certain, and I’m communicating with the responder regarding the same.
Demonstrated understanding of the responsibility of ~ubuntu-security membership
I am following credentials best practices, my disk is fully encrypted, and have 2FA enabled for all accounts.