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.

[domenkozar]

This one is really important, all other package managers support OIDC.

[ysangkok]

@domenkozar it looks like Tweag might rewrite hackage-server, see

• Propose modernising hackage-server project haskellfoundation/tech-proposals#67

maybe you could convince them to implement OIDC as part of it.

[phadej]

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.

That doesn't solve the problem of frequent releases. I don't want anyone to make releases on e.g. every commit in main branch passing (their) CI. These releases won't be low quality or broken, but they would be way too frequent.

EDIT: as gbaz said "As a append-only immutable repository its better to not have robots uploading on every PR merge."

EDIT2: I have seen people releasing versions which are essentially "after each commit". See e.g. https://hackage.haskell.org/package/mmsyn7h (and other packages by the author). These don't violate TOS in anyway, but IMO the whole stuff is on the abusive side of shared infrastructure usage. It takes just someone (with good intentions!) successfully popularizing a CI setup to do automatic publishing and Hackage (or more precisely cabal-installs local dependency solving) will become unusable. Metadata of each release of mmsyn7h (and others), and also the updates to deprecations (which I guess appear also after each upload) are stored on your machine unpacked. We really need better social or/and technical solutions before potentially making problem worse.

[TeofilC]

Worries around the frequency of releases are warranted, but to me this seems largely orthogonal to automation or trusted publishing.

Making a release to Hackage manually just takes running cabal sdist and then cabal upload. Perhaps with automation you can reduce this to just pushing a tag.

I think what we rely on to avoid excessive frequency of releases is good faith from users, rather than the difficulty of making a release.

Even then, trusted publishing doesn't make much difference here, since users can already automate releases, but take larger security risks when doing so.

I agree with @spencerjanssen that good automation would likely avoid instances where checks are forgotten before a release and so a second release has to be made to fix them.

It is also to everyone's benefit if releases can be made securely.

[domenkozar]

Exactly, these two things are orthogonal.

For secretspec sdk I manage to setup trusted publishing for all languages except Haskell.

[gbaz]

I think it must be possible to allow trusted publishing while allowing association with specific hackage users. For example, could the user who grants an an identity (via oidc) access to publish a package not be the attributed user for the package upload itself?

Also I would note that a potential hackage rewrite would be a tremendous effort in itself, and I don't think adding nice-to-haves to the initial deliverable would be a wise use of resources.

[phadej]

@TeofilC personally I would require a 2FA for each release. Uploading a release candidates may be automated, but I really want that a physical person presses few buttons to make the release happen. In other words, I don't like that you can do cabal upload --publish, IMO that is unnecessary and allows for sloppy practices.

And to make it clear: I would not ask for such strict policies if Hackage weren't append-only ever growing repository. But it is.

[phadej]

FWIW, I'd not mind if Hackage had some rate limiting for uploads, if some future (or current) (semi)automated publishing script goes rogue and starts to flood Hackage in a busy loop. This would be nice to have whether trusted publishing is implemented or not.

[domenkozar]

Could we have a separate issue for this as it's not related?

…

On Tue, 7 Jul 2026, 07:58 Oleg Grenrus, ***@***.***> wrote: *phadej* left a comment (haskell/hackage-server#1443) <#1443 (comment)> FWIW, I'd not mind if Hackage had some rate limiting for uploads, if some future (or current) (semi)automated publishing script goes rogue and starts to flood Hackage in a busy loop. This would be nice to have whether trusted publishing is implemented or not. — Reply to this email directly, view it on GitHub <#1443?email_source=notifications&email_token=AAA63AZP4JSETVCI25IZFV35DT6X7A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTIOJQGQ3DCNBRG4ZKM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4904614172>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA63A4I7NQ2TUHRD7TFUM35DT6X7AVCNFSNUABEKJSXA33TNF2G64TZHMYTEMRUGEYTQNR3JFZXG5LFHMZTMNZXGIYTOMBRGSQXMAQ> . You are receiving this because you were mentioned.Message ID: ***@***.***>