Trusted Publishing

[spencerjanssen]

Support for Trusted Publishing has become quite common among major package repositories, for example:

• PyPI
• npm
• crates.io

The benefits are well described in Why Trusted Publishers. For Hackage specifically:

• Security. The tokens issued by Hackage have unbounded lifetime and have overly broad permissions (capable of uploading to any package the user maintains). The trusted publishing model uses short-lived tokens which are tied to source repository and workflow.
• Maintainer convenience. Trusted publishing can be configured once in a set-and-forget fashion and should be more convenient than manually managing secrets. Support for trusted publishing could be integrated into existing workflows such as haskell-actions/hackage-publish for turn-key release automation.

[spencerjanssen]

I'm interested in building trusted publishing for Hackage! I thought I'd work on this in the lead up to AmeriHac which I plan on attending. Is this feature welcome? Is there anything I should know as a newcomer seeking to land such a big change?

A rough design:

• Define internal registry of trusted publishers. Support GitHub at first, but leave open to extension for GitLab etc.
• Add a CRUD UI for maintainers to configure the trust policy of packages. Concretely, for GitHub, this means organization/repository and workflow file name.
• Add an endpoint on hackage-server which takes an OIDC token as input, validates the token against one of the registered publishers, and mints a short-lived token which is authorized to publish to any packages with a matching trust policy.
• Adjust authentication on package upload and related endpoints to accept the short-lived tokens.

Key considerations:

• Package uploads won't always have a record of which user uploaded them anymore, instead the upload record will have something shaped like Either UserID TrustedPublication. From my brief survey it seems like this will have pretty wide reaching implications, including impact to historical upload logs.
• We'll need to integrate a library to validate the tokens provided by trusted publishers. There are a few libraries on Hackage that look like they might work for this purpose. Are there any guidelines for adding significant new dependencies?
• How should short-lived tokens be implemented? It could be a stateful thing where tokens are randomly generated and persisted via acid-state. This seems like the better approach to me, but I don't know the performance and operational implications of using acid-state in this way. Alternatively, there's a stateless design where tokens are claims encrypted and decrypted on the server with a secret key.

[gbaz]

This is an interesting model! However, I don't think removing package associations from uploaders is a good practice. But skimming the docs its not so sure to me that this would be necessary for implementation?

On adding new dependencies, ideally we do so only with libraries that do not require new FFI-deps, to keep the setup pipeline from becoming too difficult. This is flexible but something to aim for.

Something else to bear in mind is we really do want to discourage frequent and automated uploads, and so making them better is something I'd like to see accompanied by rate-limiting or other better mechanisms to prevent hackage from getting spammed by the ease of auto-uploads. As a append-only immutable repository its better to not have robots uploading on every PR merge.

[spencerjanssen]

However, I don't think removing package associations from uploaders is a good practice. But skimming the docs its not so sure to me that this would be necessary for implementation?

It won't be possible to associate the package upload with a Hackage user in the general case. In some cases we'll have a Github username which triggered the upload, but we don't have a mechanism to convert those into Hackage usernames.

I think the way crates.io handles this is really nice. See the version page for sigstore for example. 0.13.0 was uploaded using trusted publishing, note that the "via Github" label links to the actions run which performed the upload.

we really do want to discourage frequent and automated uploads

Sure, we don't want to encourage low quality or broken releases. However, I'd argue that automated package uploads in combination with a robust CI decreases the risk of broken releases by reducing the potential for human error.

For the initial trial of this feature we could perhaps limit trusted publishing to package candidates to keep a human in the loop.