Adventures in Open Source: Recognizing SSL’s GSoC ‘22 Contributors

Photo Caption: The 2022 GSoC contributors and their mentors show thumbs-up to a productive summer. Clockwise from left: Lakshya Gupta, Lukas Pühringer, Pradyumna Krishna, Aditya Sirish A Yelgundhalli, Santiago Torres-Arias, Abhisman Sarkar. Missing: Lenery Chen. .

This summer, the Secure Systems Lab welcomed four first-time contributors to the Google Summer of Code program. Lakshya Gupta, Pradyumna Krishna, and Lenery Chen worked on projects to improve the lab’s software supply chain project in-toto, while Abhisman Sarkar tackled a version management issue for The Update Framework (TUF), a framework that delivers secure software updates for repositories, and for programs running in the cloud.

For contributors and mentors alike, the summer appears to have been beneficial. Abhisman describes his GSoC time as “an incredible learning opportunity for people getting started with open source,” and adds, “I’ve learned a lot from my mentors regarding good code practices, and the knowledge gained up until now will be invaluable.” Gupta chimes in that he found the in-toto community “warm and welcoming.” And, mentor Lukas Pühringer, a researcher and engineer for NYU’s Secure Systems Laboratory described the experience of working with his student as “fun and fruitful.”

At the end of their summer sojourn, we reached out to our contributors and asked them to share some of the lessons they learned along the way.

Abhisman Sarkar is an undergraduate at Siksha ‘O’​ Anusandhan University in Bhubaneswar, India and was this summer’s lone contributor to the TUF project. His research tackled a significant problem for a number of open source projects: how to migrate to newer releases of a software package without worrying about version compatibility. His project, which was mapped out in a TAP, or TUF Augmentation Proposal, required two specific changes to the TUF specification: the way a repository manages specification versions, and the client update process itself. These modifications can simplify how clients find and access TUF metadata at the highest specification version that is compatible with their implementations.

Abhisman shared that he was a “newbie” when it came to TUF, and even though he was “somewhat familiar” with other open source tools, he still acknowledged that “getting into open source was somewhat daunting to me.” What drew him to the TUF project was that it used Python, and “the use of a familiar language eased my tensions.” As the project moved forward, he found his skills with the language developing to the point where he could joke about calling himself “a Pythonista.” He also pointed out that he got to know and apply what he learned about Git and Github and came to appreciate how great a tool Git is in source code management. Despite some initial anxieties, he found that acting immediately on what he was learning was also “the most fun part” of the GSoC experience.

His work was conducted under mentors Marina Moore of NYU and Zack Newman of Chainguard.

For Lakshya Gupta, a student at Birla Institute of Technology and Science in South Goa, India, choosing to work on modifying the in-toto Jenkins plug-in had a lot to do with how the project fit with other research he had performed to date. He also saw it as an opportunity to deepen his knowledge of Jenkins and, on a broader scope, learn more about how CI/CD (Continuous Integration and Continuous Delivery) processes work.

The project Lakshya took on can enable users to generate in-toto attestations with SLSA provenance metadata. The additional information that can be stored in the provenance format– including the ID of the builder, the source that triggered the build, and its start and end times– can deliver enhanced security through greater transparency. As documented in the blog he shared with GSoC, Lakshya’s contributions were two-fold. First, he updated the in-toto-java library containing the model code for SLSA Provenance to support v0.2. And, second, he updated the Jenkins plugin so the in-toto library could generate SLSA provenance for builds performed in Jenkins instances.

Lakshya confessed that one of the hardest challenges of the project was “overcoming imposter syndrome and learning what was required.” After discussing the problems with his mentor, Aditya Sirish A. Yelgundhalli, a Ph.D. candidate at NYU Tandon, “we found a way to proceed by dividing the project into smaller chunks and completing one thing at a time.” Another hurdle he cited was “upgrading the project to JDK version 11, a process that included a lot of back-and-forth communication and code changes to the plugin repository.”

Pradyumna Krishna, who completed his undergraduate degree from the Deen Dayal Upadhyaya College of the University of Delhi in 2022, spent his summer working on a project called the Dead Simple Signing Envelope. DSSE is a novel standard for signing arbitrary data. The actual tasks he performed over the summer included implementing the protocol for the creation and verification of DSSE signatures, and developing “a working, fully tested, and documented DSSE signature wrapper for in-toto metadata, that may be used interchangeably with the existing signature wrapper.”

Like Abhisman, Pradyumna liked that the project was based on Python, a programming language with which he had experience. Throughout the summer, he noted he was able to build on that experience, learning “some new things, like how the release cycle works in software development, and how to maintain code quality.” But, beyond that, he was drawn to developing DSSE because “it deals with software security and encryption.” Particularly challenging, but also energizing, was that the implementation took place in a library that in-toto shares with its sister project, TUF, and the goal was to accommodate both projects. Pradyumna’s primary mentor, Pühringer, notes that he “implemented a security critical enhancement in a library that is shared by two security frameworks and used in production to secure real world software supply chains.”

Perhaps the most valuable skills Pradyumna developed over the summer were not technical, but rather interpersonal. “I was not comfortable communicating with people in English,” he explained, adding that a lack of English proficiency “sometimes made it hard for me to express a scenario.” But, he adds, “with the help and support of mentors, it never set me back.”

Last, but certainly not least, Lenery Chen, a master’s degree student at Southern University of Science and Technology in Shenzhen, China, described his work this summer as ”a small step, but it is these small steps that build up supply-chain security.” Specifically, he, like Lakshya, was involved in developing SLSA provenance support, and like Pradyumna, his work required developing a library for DSSE. But, Lenery’s focus was on using the Rust implementation of in-toto to apply these tools to the Rebuilderd project, an open source verification system that affirms any package built in an identical environment must be identical to the original.

Though Lenery was new to GSoC, he observed that he had participated for three years “in a similar project named Open Source Promotion Plan, hosted by the Institute of Software of the Chinese Academy of Sciences.” He was also not completely new to in-toto, as he reported applying for an in-toto project last year, but “not approaching the proposal seriously.” So as not to make that mistake again, “this time I worked with in-toto before GSoC began by fixing some minor issues.”

Lenery came to the GSoC program hoping to gain experience in “designing a larger real project,” involving “multi-person cooperative development and communication.” Looking back on the experience, he commented that it was “inspiring” to work on a “project used by some giant companies.”

All of the participants mentioned that they would like to continue as contributors in the future should their academic and work schedules permit. Abhisman noted he wishes “to work on more TAPs and build newer features for TUF implementations. The people I’ve been introduced to and the learning culture was amazing and I do not want to let go of that.” Lenery adds, “ I will continue to advance the development, until in-toto-rs becomes stable. It’s my responsibility to finish what I started.”