Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create a listserve for Sigstore clients and tooling to announce deprecations/comms #179

Open
asraa opened this issue Nov 7, 2022 · 5 comments

Comments

@asraa
Copy link
Contributor

asraa commented Nov 7, 2022

It would be nice to have a Sigstore client listserve that can help automate communications that need to be delivered to Sigstore clients, including:

  • Deprecation notices
  • Breaking changes or updates in services
  • Security issues
  • etc.

It would be nice to also have tooling around creating these emails via a GitHub issue. E.g. if we post a public PR/issue on sigstore/community regarding Sigstore services. Then with applying a certain label or comment, we can issue an email to the list-serve with the content. Or maybe that's too complicated, but it allows for documentation of the issue outside of a listserve if public.

@davelester
Copy link

+1! These are communications that can easily be lost in Slack today. How about dev-announce@?

I'd suggest that we use Groups.io to power this for sigstore.dev, similar to how OpenSSF lists work today. If that's a worthwhile path I'm happy to help find out how to make that happen. I think there may be a need for additional lists as well (perhaps best discussed in a separate GH issue).

@lukehinds
Copy link
Member

I had been thinking the same, so +1 from me.

@asraa
Copy link
Contributor Author

asraa commented Nov 7, 2022

Yes, thanks! That would be great: even just starting with the creation of a groups.io listserve would be great.

I'll be happy to file issues on various clients that want access.

@lukehinds
Copy link
Member

we do have google services enable on email@sigstore.dev , could that be leveraged at all?

@lukehinds
Copy link
Member

lukehinds commented Nov 8, 2022

A good example of why this is needed:

image

There have been a lot of messages like this in slack, and I am pretty sure this a non-backwards compatible change was made between cosign and how the tuf root is transported (please correct me if I am wrong).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants