Consider whether to publish from CI

[kylebarron]

See description here: https://crates.io/docs/trusted-publishing

Trusted Publishing is a secure way to publish your Rust crates from CI/CD platforms like GitHub Actions and GitLab CI/CD without manually managing API tokens. It uses OpenID Connect (OIDC) to verify that your workflow is running from your repository, then provides a short-lived token for publishing.

Instead of storing long-lived API tokens in your repository secrets, Trusted Publishing allows your CI/CD platform to authenticate directly with crates.io using cryptographically signed tokens that prove the workflow's identity.

I've set this up on a few repos and would be happy to make a PR for this as well, though I'm busy and then on vacation next week.

[michaelkirk]

The value proposition vs having long lived tokens in CI is clear, but we currently don't have long lived tokens in CI, because we don't publish geo from CI.

I think the bigger story implied here is "start publishing geo from CI", for which the value proposition is more complicated, and the details would need to be fleshed out. From there I think using trusted publishing makes sense iff we decided to start publishing from CI.

A couple questions that immediately jump to mind:

What happens to the current publishers? Are they still allowed to manually publish?

Currently publishing is a separate permission from committing to the repo. What does that look like in the world where we are publishing from CI

I might have other questions, but these ones popped up first.

[urschrei]

@michaelkirk

1. AIUI nothing would prevent current publishers from continuing to be allowed to publish: there isn't (as yet) a way to disable the existing flow. Are you asking because that's something you want? I assume not, just checking (I like the idea of there being one way to do a thing, but in this instance I don't like the idea of that way depending on a CI provider, the fact that we manage the publishers using GitHub notwithstanding…)

2. Best practice is to define a separate publishing workflow which can only be triggered by e.g. members of geo-publishers – you have all the existing protection machinery for workflows at your disposal to restrict it.

I'm on the fence; I am an enthusiastic user of trusted publishing for my Python packages, but I'm not sure that it would necessarily be an improvement for geo. I'm open to being persuaded though.

[michaelkirk]

1. [...] Are you asking because that's something you want?

I don't especially want to publish geo via CI. I'm a fossil and generally prefer low tech workflows.

I guess my point is, although "trusted publishing" sounds like some kind of security win, if we were to keep all our existing publishing methods while adding a new one, it's a strictly worse security posture, despite the name. It could be a win if we were already publishing geo via CI, but we're not.

2. Best practice is to define a separate publishing workflow [...]

That makes sense! Thanks.

[kylebarron]

I renamed the title of this issue. I don't have strong feelings about it. I'm just used to publishing via CI in my projects because it provides an easily reproducible way to publish and it ensures that I can easily hand off publishing to other people when I add new contributors.

It's possible neither of those limitations really apply here because 1) running cargo publish is so easy and 2) we already have a mechanism for doing this via the github publishers group.

Happy to close if you wish. FWIW I added it to the wkb crate here: georust/wkb#89

[michaelkirk]

I'm happy to leave the issue open for more discussion.

As I said, it's not my personal preference, but I'm not actually allergic to publishing from CI if other geo publishers want to champion it. Mostly I just wanted to clarify what we were talking about — thanks for updating the issue title.

[weiznich]

As I had a similar discussion around trusted publishing as "safety indicator" in other places, I would like to add the following information to this discussion: Trusted publishing only solves a problem around token access. It doesn’t make the published result any more trustworthy than having the token in a secure location like your system keychain. Therefore on its on it cannot carry any information about the security measures an author took.

See this zulip discussion for more details.