Hacker News Reader

Comment by kibwen | Hacker News Reader

Are there any public package repos that do package signing well, or is this still an unsolved problem?

I think Maven does PGP fairly well. It's not perfect, but enh.

Sonatype are the community stewards. They make sure you have control over and email address and a packaging namespace. PGP is nice because it _requires_ an email address tied to a cert.

They _require_ signatures for _every_ artifact uploaded.

The maven repository manager makes your release transactional. Either all of your artifacts are signed and the signatures match, or none of the artifacts are published.

Your release is rejected if you fail to pass the test.

After the checks, you are given the option to publish the transaction or not.

There is no undo button, as it should be.

I also reported a bug/security issue to Sonatype and they fixed it within a few weeks.

There is room for improvement:

I think they could get stricter and require the signing keys be listed in the pom or whatever build file you use.

Maven does some signature checking, but it oddly enough doesn't do pgp verification. Given that 100% of signatures are checked on upload, it technically is redundant since nearly everything is TLS these days.

I think Sonatype should publish a transparency keymap. This would probably be an actual good real-world use case for a blockchain too. KeyId -> Artifact Namespace controlled.

Does Maven Central check that the GPG key used matches anything? Or can you just use whatever random key to sign your packages?

Yes. See their requirements.

No. You have to use the same approved key that’s associated with the artifact namespace.

I was checking their requirements pages and I didn't see any mention how the keys are associated with anything, that is why I was asking

https://central.sonatype.org/publish/requirements/#sign-file...

https://central.sonatype.org/publish/requirements/gpg/

It only says:

> These identifiers are essential as they will be seen by anyone downloading a software artifact and validating a signature

but nothing about associating the keys with account or anything.

You're not associating keys with an account; you're associating keys with a maven namespace. I guess you do have to have an account to post a artifact into a staging repository, but at the end of the day, the keys have to match the namespace and to quote Stone Cold Steve Austin: And thats the bottom line.

So for instance, I now control this maven namespace:

com.github.exabrial

When I created my Sonatype account, I signed up and verified my email. I then had to give them a PGP public key and told them I wanted to control that namespace. Since the namespace was un-occupied, they were like sure np.

Now, whenever I publish artifacts into that maven namespace, they must be signed with that PGP key.

As an example, you can see the associated signature files for all of the artifacts for this release in the repository: https://repo1.maven.org/maven2/com/github/exabrial/logback-o...

repo here: https://github.com/exabrial/logback-openwire-appender if you want to look at the build configuration in the pom.xml

> Sonatype are the community stewards. They make sure you have control over and email address and a packaging namespace. PGP is nice because it _requires_ an email address tied to a cert.

This isn't a property anywhere in PGP: a PGP identity can be an email, or it can be any other free-form identifier.

Individual keyservers can gatekeep inclusion based on email verification (which itself is flimsy, but ignoring that for the moment), but there's no strong guarantee that any particular keyserver does that (or will continue to do it, as a matter of policy). Uploading certs for "bill@microsoft.com" was a joke on the SKS servers for years.

They check you have control over the email address.

Who is “they”?

The current OpenPGP keyserver does this, but again: that’s new, and it’s a matter of policy, not protocol. PGP itself isn’t involved in that.

Sonatype

That’s good! But again: that’s not a property of PGP. It’s an operational burden that an unrelated (corporate?) entity has chosen to assume.

Essentially. The decision was actually made by the maven central maintainers at the apache source foundation, and Sonatype implemented the decision.

I write both Java and Python for a living

trying to guide junior devs in the right direction for python is nearly impossible (don't use setup.py, it's deprecated, ah except that, ah setup.cfg is now too, use setup.toml, ah I'll just check the docs, crap they're incomplete and inconsistent)

you can't call your package that as someone already used that name on the internet and it's a flat namespace, sorry you can't share modules between teams because everyone has their own mini pypi to push to and the tooling is actively hostile against namespacing

and the same is true of the build chain, trying to version the packages, even getting coherent dependency resolution between machines is a complete disaster

Java sorted out all the packaging mess 20 years ago, meanwhile Python continues to re-invent everything badly, and not just badly, really really badly

meanwhile pypa are faffing about mission statements and making github uploads very slightly more secure

python needs a Sonatype to replace pypa

Debian packages, although they aren't signed but "use apt-secure (also known as secure apt) which is a tool that will allow a system administrator to test the integrity of the packages downloaded" [1].

1. https://www.debian.org/doc/manuals/securing-debian-manual/de...

I'm tempted to give in to the claim that a problem that is fundamentally a liability concern, and therefore needs legal fallback, is unlikely to have a technical solution.

Closest you can get is probably the Apple model?

NuGet (the .net package manager) maybe?

Reply on news.ycombinator.com