Repository navigation
Trusted Publishing #1443
Description
Support for Trusted Publishing has become quite common among major package repositories, for example:
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.
Reacted by Domen Kožar and Jappie Klooster
Activity
spencerjanssen commentedon Nov 30, 2025
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:
organization/repositoryand workflow file name.Key considerations:
Either UserID TrustedPublication. From my brief survey it seems like this will have pretty wide reaching implications, including impact to historical upload logs.acid-state. This seems like the better approach to me, but I don't know the performance and operational implications of usingacid-statein this way. Alternatively, there's a stateless design where tokens are claims encrypted and decrypted on the server with a secret key.gbaz commentedon Nov 30, 2025
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 commentedon Dec 2, 2025
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.0was uploaded using trusted publishing, note that the "via Github" label links to the actions run which performed the upload.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 commentedon Jul 3, 2026
This one is really important, all other package managers support OIDC.
ysangkok commentedon Jul 4, 2026
@domenkozar it looks like Tweag might rewrite hackage-server, see
maybe you could convince them to implement OIDC as part of it.
phadej commentedon Jul 6, 2026
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 ofmmsyn7h(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 commentedon Jul 6, 2026
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 sdistand thencabal 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 commentedon Jul 6, 2026
Exactly, these two things are orthogonal.
For secretspec sdk I manage to setup trusted publishing for all languages except Haskell.
gbaz commentedon Jul 6, 2026
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 commentedon Jul 7, 2026
@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 commentedon Jul 7, 2026
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 commentedon Jul 7, 2026