PGP vs. sigstore: A recap of the match at Maven Central

December 23, 2022 By Aaron Linskens

8 minute read time

At Sonatype, a great presentation never dies. Nor does it simply fade away. While you might watch a presentation given by one of our team members onsite or online for a developer conference or community event, you can also catch a faithful adaptation in written form on our blog. This is one such case. Hervé Boutemy delivered this presentation at Devoxx Belgium in October 2022, and we’ve sought to replicate his words and je ne sais quoi below.

Step into the code-signing ring

Ladies and gentlemen, welcome to today’s main event!

The venue is Devoxx Belgium. In one corner, we have PGP — the veteran code-signing tool that’s been a mainstay in the industry for decades. In the other corner, we have sigstore— the new kid on the block, making waves with its innovative approach to code signing. This match is sure to be a showdown of epic proportions, as we pit these two contenders against each other to see who comes out on top.

Who will emerge victorious? Will PGP's years of experience give it the edge it needs to defend its title as champion? Or will sigstore's fresh perspective and holistic approach secure a win in this major match?

Let's find out, as we bring you the highly anticipated PGP vs. sigstore match at Maven Central!

What brought us here

To identify and remediate security issues in open source software, a good place to start would be to determine where the software came from and how it was built.

One method to see if a piece of software you use is what it claims to be: check it for a cryptographic digital signature to verify the identity of the author or build system.

While there need not be a competition between code-signing tools, a comparison of a couple options illustrates how code signing technology has evolved in the last couple of decades.

Who judged the match

Hervé Boutemy took the role of referee for this match-up.

 

Picture of Herve Boutemy

By day, Hervé is a solutions architect at Sonatype, working on and with a team that manages the Maven Central Repository. By night and weekend, he is an open source contributor, Maven maintainer and Apache Software Foundation member.

Most recently, Hervé dedicated time to developing Reproducible Builds and sigstore integrations from a Maven point of view.

Despite being a referee, Hervé took an active role in this match and began by polling the spectators. From an audience of mostly Java developers, he collected the following results:

  • Everybody downloads from Maven Central, but few check PGP signatures
  • Few publish to Maven Central, fewer use PGP for signing, and only one person claimed to have a good signing experience

From this, Hervé made an official ruling of a key problem with code signing—everyone wants to sign, but nobody likes to check signatures.

Why signatures are important

We consume lots of components from many different ecosystems—libraries, frameworks, and tools in Java, JavaScript, Python, and NuGet, for example.

Bar graph showing the increase of open source consumption across Java, Javascript, Python and Nuget

As noted in the latest State of the Software Supply Chain report: “In 2022, the number of open source dependencies being downloaded and integrated into software grew by an estimated average of 33% across all the monitored ecosystems.”

With increasing complexity in software supply chains, hackers no longer wait for a disclosed vulnerability to exploit. Better to directly inject malicious code when you trick unsuspecting developers into downloading a supposedly legitimate component that actually contains malware.

Graph showing a 650% increase in software supply chain attacks since 2020

Rather than exploit a vulnerability, a hacker exploits a developer’s expectation that simply inputting coordinates into a build tool will download the exact artifact they want from a public repository.

The route from an open source project to your laptop is anything but simple and straightforward. There are many places along the software supply chain for a hacker to hide a malicious component and trick you into downloading it.

Illustration showing how attacks on a software supply chain works, as one developer puts code into a repository

Signatures seek to prevent this scenario. A public project has an identity. Maintainers create a digital signature to provide verification of that identity. If they associate their signature to each of their components, you can check that signature to ensure you bring the official component and not an unofficial (potentially malicious) one into your own project.

Illustration with one developer creating open source code with a signature, and the depiction of that going to another developer and a hacker, with crossed out code, illustrating it can't be changed with a signature.

Hervé wrapped up this contextual information with one key assertion: code signatures will only provide a proactive means of preventing malware from entering your build environment if you actually check the signature beforehand. Hackers can generate their own signatures, so it’s critical to compare if the signature of a component matches the official signature of the project.

PGP

PGP stands for Pretty Good Privacy. Modest in its name. Encryption is its game.

With unusual beginnings as a public algorithm on a proprietary piece of software in 1991, it became the de-facto standard for anyone who wanted to use digital signature encryption in the 90s.

In order to stay nimble and reach an even larger audience, PGP took the next step in 2000 and evolved into an open standard known as OpenPGP. That open standard breathed life into a Free Software Foundation implementation— GnuPG (a.k.a., GPG).

Despite any UX-confusion of PGP and GPG, the Apache Software Foundation in 2002 made PGP its officially enforced signature policy on their releases.

Screen view of download page for Apache Maven 3.8.6 with a red box highlighting that Apache Software Foundation  made PGP its officially enforced signature policy on their releases.

The Apache Maven project reused this policy for Maven Central in 2005.

Given how PGP has reigned as the top code-signing tool for more than 20 years, why would any new option warrant consideration?

Despite its storied reputation, this veteran code-signing tool received the following judgment of shortcomings by Hervé:

  • Complex key management
    • What do you do if you lose your private key?
    • What if you did not copy your key from your primary computer and currently cannot access that device?
    • What if your key is stolen?
  • Key rotation, key revocation
  • User needs high level of knowledge of cryptographic algorithms

The overall judgment from Hervé: It’s a pain to sign and check PGP signatures. The model of trust for PGP did not scale.

sigstore

In sigstore, a young challenger seeks to streamline the user experience by promising “an easy keyless signature” process, both for signing and checking. While only on the scene since mid-2020, sigstore quickly found favor under the Linux Foundation with additional management from OpenSSF.

While the “keyless” part remains a work in progress, sigstore gained momentum quickly with support from multiple reputable institutions, such as Google, Red Hat, and Purdue University.

Hervé gave a concise rundown of a few pieces of software sigstore keeps in its corner:

  • Cosign: a tool for container signing, verification, and storage in registry
  • Fulcio: a certificate authority for short-term signing certs that issues certificates based on an OpenID Connect identity provider
  • Rekor: a transparency log that records every signature in a non-modifiable way

In addition to this team of software components, sigstore also works to provide a public instance of Fulcio and Rekor specifically for open source projects instead of leaving every OSS project and ecosystem to create its own separate instance. With this common instance, sigstore lays the groundwork for a community-managed public-service initiative.

Hervé then raised the stakes with a live demonstration of a sigstore Java POC signing experience.

From this demo, the new kid on the block in code signing received the following judgements from Hervé:

  • No cumbersome key management. Easy authentication. Easy to sign.
  • Email as a signature identity feels natural.
  • Human-understandable signature-checking process.
  • While the signature checking is easy with email, the verification process still requires some refinement.

The overall judgment from Hervé: sigstore’s user experience provides a superior signing and checking process. And it’s not a question of if but when full sigstore support will arrive in Maven Central.

And the winner is…

It’s a draw! Although the newcomer sigstore gave long-time champion PGP a run for its money, it’s still too early to crown an absolute new winner in the code-signing space. Sigstore continues to show great promise with its team of software tools that comprise an automated, holistic approach to signing and checking. But there’s still a way to go in its ongoing challenge of stalwart veteran PGP. Thank you to both contenders for an exciting and memorable match.

 

Tags: secure software supply chain, Open Source, Maven, devsecops, DevZone, code signing

Written by Aaron Linskens

Aaron is a technical writer on Sonatype's Marketing team. He works at a crossroads of technical writing, developer advocacy, software development, and open source. He aims to get developers and non-technical collaborators to work well together via experimentation, feedback, and iteration so they can build the right software.