Project rename

[lukehinds]

A few folks have raised the sigstore/sigstore project is not immediately obvious as to its role. I think just being called 'sigstore' does not help in this regard.

I would like to propose renaming to sigstore-go. It then follows the same convention as the others, sigstore-js, sigstore-python, sigstore-rs, sigstore-rubygems etc.

From what we know, GH will 301 https://github.com/sigstore/sigstore to https://github.com/sigstore/sigstore-go

I expect it should be as simple as:

• refactor code to sigstore-go
• rename repository
• ship a release

Does this order sound right, am I missing anything?

cc @cpanato , @dlorenc , @bobcallaway , @priyawadhwa (for chains)

[dlorenc]

We've cut a 1.0 release, so we can't really just rename it without also bumping the major version to v2.

We could rename the repository but keep the old import path.

[cpanato]

or we create a new repository and archive this one, and in the new, we can keep the same versioning

[znewman01]

[unsolicited opinion 😄] I would object to such a rename, and not just for logistical reasons.

I think there should be two Sigstore libraries in Go—one that's used by Fulcio/Rekor (the role that sigstore/sigstore plays now), and one that uses Fulcio/Rekor and exposes a higher-level API. The latter plays a role very similar to sigstore-{rust,java,python,js,etc} and should be called sigstore-go.

  graph LR;
      fulcio-->s/s;
      rekor-->s/s;
      sigstore-go-->s/s;
      sigstore-go-->fulcio;
      sigstore-go-->rekor;
      cosign-->sigstore-go;

sigstore-go would expose an interface with high level methods to sign/verify, and that's what most programmatic Go users should use; cosign would be a relatively thin wrapper around sigstore-go and most of its logic would relate to CLI and OCI.

CC @imjasonh who I believe has expressed similar sentiments

[lukehinds]

@znewman01 , for what is a lot of work and something that would need a lot of co-ordination, what benefits would a substantial refactor / re-architect such as this bring to merit the disruption and work needed? I would expect us to be facing pains somehow with the current situation, to merit this happening.

[lukehinds]

or we create a new repository and archive this one, and in the new, we can keep the same versioning

would it be a fork so we retain commit history?

[znewman01]

I would expect us to be facing pains somehow with the current situation, to merit this happening.

I think we need such a library regardless. If you want to write an application with a Sigstore client in Go right now, you have two options:

1. Build it yourself using s/s, Fulcio, Rekor, and (possibly) go-tuf. This is basically recreating the proposed sigstore-go as a library inside of your application, and it's error-prone; I don't think we should be recommending this.
2. Use Cosign. The Cosign API is more evolved than designed and even as someone pretty familiar with the project, a simple application like "sign a blob" needs me to understand a lot of details about how Sigstore works. Further, you wind up pulling in a pretty big dependency tree, especially relating to OCI.

I'm coming at this from the angle of a potential integration with a non-container-related service (where blob signing is the primary goal). I think we could have a package of Cosign that exposes a carefully-crafted subset of functionality and that doesn't pull in all the dependencies, but at that point we've just described a sigstore-go library.

for what is a lot of work and something that would need a lot of co-ordination, what benefits would a substantial refactor / re-architect such as this bring to merit the disruption and work needed?

I don't think it would entail a big refactor so much as a change to write a greenfield Sigstore client in Go, using the lessons that we've learned from developing Cosign and the other Sigstore clients. Already I think that the sigstore-python API, for instance, is looking really good and easy to use, and it's likely because of the benefits of hindsight. Then we could migrate Cosign over slowly, if desired.

But regardless of whether we do write such a library, I think a rename of s/s to sigstore-go would be misleading because it doesn't expose a complete Sigstore interface for clients. Further, I don't think it ever can (or should!): such a thing would depend on the Rekor and Fulcio APIs. Even if we didn't add a dependency on the Rekor/Fulcio client code, it's still a conceptual dependency.

s/s is a super-important library to have as "shared code for the Go Sigstore ecosystem" and it does a good job of that; I think a second job as "Sigstore client library for Go" is best done elsewhere.

[bobcallaway]

strong +1 to @znewman01's comments. While I wouldn't name this repo sigstore/sigstore with hindsight, I think we could solve that with a better README, repo description, and a blog post or two (and potentially consider renaming down the road).

Creating a proper sigstore-go client (functionally equivalent to sigstore-{java,python,rs}) and driving a simpler cosign codebase is a more important goal for the community IMO.

[imjasonh]

+1 to creating a greenfield sigstore-go client with the learnings of cosign,policy-controller,gitsign,sget,etc, and eventually intended to be used by those.

It might make sense to start hacking on that in a personal repo somewhere, until we're relatively happy with the shape of it, then we can have sigstore adopt it. Otherwise, if we create it in the sigstore GH org, we need to be very clear that it's not ready for wide usage yet.

[sabre1041]

+1 to creating a consumable and reusable library that can not only be integrated into tooling within sigstore, but allow for integrations by 3rd party components.

@imjasonh and I discussed it briefly earlier this week

[lukehinds]

Seems to be some consensus this is the way forwards and I have been saying for a while now that cosign needs to reduce its bloat, but I am still not seeing why they need for two separate libraries? Why not have a single sigstore-go and continue refactor out of cosign into here?

[znewman01]

Why not have a single sigstore-go and continue refactor out of cosign into here?

I can't think of a way to do this without cycles:

graph LR
   fulcio-->sigstore-go
   rekor-->sigstore-go
   sigstore-go-->fulcio
   sigstore-go-->rekor
   cosign_and_friends-->sigstore-go

If we don't have sigstore-go depend on Fulcio/Rekor we can't be a one-stop shop library for end users. You could "not depend on" Fulcio and Rekor and the same way that sigstore-{python,rust,...} don't depend on Fulcio and Rekor: by using their APIs. But this means we (1) don't get to use the proto interface from those repos, and (2) is still a dependency, it's just now implicit.

But if we don't have Fulcio/Rekor depend on sigstore-go we'd need to duplicate a lot of the TUF logic, signature format logic, etc. So we'd want to factor that out into a new library and then we're right where we started.

[cpanato]

or we create a new repository and archive this one, and in the new, we can keep the same versioning

would it be a fork so we retain commit history?

we can copy with the entire git history

[lukehinds]

OK, I am somewhat (but still not entirely) convinced. As long as we have the sufficient numbers of hands on keyboards to do the work and we don't break anything for users, the consensus seems to be here to proceed.

I expect this could benefit from being shaken out in a doc first. Are you nominating yourself as point person @znewman01 :) ?

[znewman01]

Sure, I can try to throw together a 1-to-2-pager about the Sigstore landscape in Go. Will link here. I can also briefly touch on:

1. Relationship to other language clients and the specification.
2. What renaming, if anything, should occur.
3. Examples of APIs that we can learn from.

I think the API for a potential sigstore-go library is would be better in its own repo, so maybe we can find a team to do that if I can get rough consensus on the above proposal in the community meeting.

[znewman01]

See #695 which runs into this issue.

[znewman01]

Here is a draft doc including many of my thoughts here: https://docs.google.com/document/d/1aZfk1TlzcuaO0uz76M9D26-gAvoZLn0oCAKvkbuhcPM/edit#

Feedback very welcome! I'll put it on the agenda for the community meeting tomorrow.

[haydentherapper]

We good to close this out? We won’t rename this library, and will focus on Sigstore-go