Folks want to contribute , lets make it easy for them. We can start by using good first issues / help wanted.

This is required for debug assistance and security vulnerability assessment (for users to establish whether or not they are running an affected version).

At one point we had actual names in the CODEOWNERS files, but that switched at some point to point to a GitHub team in each repo. That works fine, but these teams are not publicly visible (I don't think), so people can't see who is a maintainer on each repo. We should switch this back, or separately document the set of people in each team.

This issue is to receive nominations for the Best User Adopter Award 2022.

This award recognizes an individual, team or organization who have adopted Sigstore to secure and protect their software, and have shared their impactful Sigstore story so that others may also learn from their journey.

To nominate someone, reply to this issue with the following:

Full name of the person, team or organization you’re nominating
Short description of where they use Sigstore and why they should win.
Nomination Deadline: Tuesday, September 20, 2022

More details are available here: https://github.com/sigstore/community/tree/main/awards

A lot of repos are running unit / integration tests against changes such as a markdown edit.

This causes unnecessary use of resources and not in the interest of sustainable computing.

We should find some way to skip CI runs, perhaps based on extensions, .txt, .md

We should really start maintaining changelogs. Decide how we want to do this? Is this something we can implement.

PRs are frequently opened without referencing existing issues. This results in features that have not been thoroughly vetted being approved, and also runs the risk of two developers working on the same feature.

I propose that all PRs should have an attached issue. This can be enforced with a bot. Examples of PRs that should have issues:

• Bug that is impacting many users
• New feature
• API change
• New command line flags
• Major refactoring

It may be worth considering exceptions for small fixes or minor changes around documentation.

For larger features, we should encourage design docs or discussion in the issue before a feature is coded up. This frontloads conversations for contentious or difficult features, saving developers time as PR reviews become focused on code quality and not feature-specific issues.

Context: New contributor friction log

This issue is to receive nominations for the Most Valuable Sigstore Contributor Award 2022.

This award recognizes excellence of technical contributions to Sigstore. This individual commits key pieces to projects and, more importantly, contributes in a way that benefits the project neutrally as a whole.

To nominate someone, reply to this issue with the following:

1. Full name of the person you’re nominating
2. Short description of their contributions to Sigstore and why they should win.

Nomination Deadline: Tuesday, September 20, 2022

More details are available here: https://github.com/sigstore/community/tree/main/awards

Description

Add a document to describe the release process to release a specific project, ie, cosign

This Document will be added for each project and have the steps required to release that piece of software.

Hi!

The recent rekor sharding broke our SLSA builders ( slsa-framework/slsa-github-generator#876 (comment)) and @laurentsimon and I were discussing that we have been finding almost all production issues reported in our e2e test suite.

What we were wondering is if we can either donate our e2e testing to the upstream community: we can file issues against sigstore when our tests fail due to verification errors. OR more importantly, sigstore can maintain a list of CRITICAL projects that must continue to satisfy rekor lookups, or cosign verifications, before rolling out any server changes.

Is this possible?

Bazel CI does this for critical projects:

This issue is to receive nominations for the Best Sigstore Evangelist Award 2022.

This award recognizes a champion for Sigstore projects. This individual helps spread awareness of Sigstore and its projects. They bring Sigstore to new communities, driving interest and excitement around the ecosystem.

To nominate someone, reply to this issue with the following:

Full name of the person you’re nominating
Short description of their contributions to Sigstore and why they should win.
Nomination Deadline: Tuesday, September 20, 2022

More details are available here: https://github.com/sigstore/community/tree/main/awards

I was looking for the Sigstore case-studies and couldn't easily find them indexed in one place. I was able to find them by searching on Medium, but perhaps we can list them somewhere (in the community repo? on sigstore.dev?) with a brief summary to help potential readers find them?

Case-studies I found:

• DB Schenker: internal supply chain integrity https://blog.sigstore.dev/securing-your-software-supply-chain-without-changing-your-devops-workflow-e23393a5fffa
• Verizon: attaining SLSA level 3 https://blog.sigstore.dev/security-by-default-how-verizon-new-business-incubation-uses-sigstore-to-demonstrate-provenance-7beed5714738
• Autodesk: meeting FedRAMP compliance requirements https://blog.sigstore.dev/using-sigstore-to-meet-fedramp-compliance-at-autodesk-6f645a920abc

Maybe we can add a page here with a list of everyone running mirrors, auditors, monitors, etc.

People can add their own!

This issue was automatically created by Allstar.

Security Policy Violation
Block force push not configured for branch main

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

This is a distinct issue to track progress towards a logo for the gitsign subproject, though is part of the general sigstore logo refresh stage 2, see #61.

Gitsign should have it's own logo that is distinct but also in keeping with the new Sigstore logo.

Description

The page shows that the meeting will start at 1030am CST, which is incorrect. The meeting actually starts at 1130am CST.

Bellow that, it is mentioned that the meeting in the local time is 1130am CDT which is also incorrect incorrect because we are not in CDT anymore. Daylight Saving Time (Central Daylight Time (CDT), UTC -5) ended on Nov 7, 2021 and will restart on March 13, 2022.

So it looks like the times and time zones got mixed on the page, which is confusing.

When a contributor adds a significant feature, an architecture diagram should accompany the feature. This is helpful for reviewers to understand more about the feature, and for other contributors to understand how to properly use the feature.

This has been brought up in Fulcio too - sigstore/fulcio#373

Context: New contributor friction log

Creating this issue to start gathering thoughts on crates sigstore signing.

Current Status

Cargo performs no signing verification of crates at present.

Users running the cargo install command will download unsigned code which will be compiled and executed.

There has been discussions around using TUF, but progress is arguably very slow, as its been in discussion for over 5 years now [0] / [1].

In thread [0] there appears to be a preference for a TUF based CA / PKI: "So, my vote is for a centrally managed PKI, and more specifically for TUF."

A pull request was made to sign registry index commits [2], was never merged and discussion has moved to this issue [3]. Discussions there have dried up (last comment was late last year). Two sigstore community folks @trishankatdatadog and @joshuagl comment on a document produced here at [4] which supports what we all believe, TUF + TLOGS is a "belt and braces" approach and they compliment each other. I know @SantiagoTorres has looked at this before.

[0] rust-lang/crates.io#75
[1] https://www.reddit.com/r/rust/comments/6qjpzf/could_the_security_of_cargo_and_the_crates_system/
[2] rust-lang/rfcs#2474
[3] rust-lang/cargo#4768
[4] https://ssl.engineering.nyu.edu/blog/2020-02-03-transparent-logs

Branching off from the sharding discussion sigstore/rekor#806 , we considered that clients could perhaps benefit from a retry handler in event of system outage. There was proposal made that we could benefit from a general client guideline / standard. This would not be concerned with the specifics of the client itself, more on how clients would best be suited to interact with sigstore services (rekor, odic, fulcio).

Description

Add the CoC document

Add in the https://github.com/sigstore/.github and then link in the other repos

Document what is the expected duties of a maintainer and how a maintainer is nominated and on boarded (and off boarded). Some considerations:

• Can someone self nominate, or should an existing maintainer nominate the individual
• Should there be an outline of what makes a good maintainer (contributions (perhaps a key feature), thoughtful reviews etc). I don't think we can set a criteria and enforce it, but we can at least give contributors some insight into some level of expectation we have.
• Should there be some expectations of what a maintainer should do (chop the wood / carry water , so triage issues / house keep the project).

• Create a GitHub Team to hold the members that will help to run the releases for Sigstore
• Give write permissions and permissions to create/edit milestones/labels
• Maybe permissions to configure branch protection and webhooks

/cc @lukehinds

This can detect any modifications outside out of this repo to prevent the repo permissions from deviating from what's been declared in Pulumi

cc @cpanato

The Sigstore ecosystem supports many features, and at times it's hard to find how to use non-core features.

I propose that PRs with user-facing features must be accompanied with documentation changes. We could enforce by bot that all flag changes have help text. Help text could then be automatically parsed and added to the Sigstore doc website.

Context: New contributor friction log

As discussed in this week's community meeting, there was a strong desire to see smaller PRs. This may be hard to enforce via a bot, so we should initially rely on reviewers to ask contributors to keep PRs small. Combined with #45, it should be easy for reviewers to keep track of large feature development across multiple PRs.

Context: New contributor friction log

cc @mattmoor

With the security policy nested under the Community repo, repos like Rekor show up as "no security policy" -- whomp whomp :(

Could probably just have the security.md's in other repos point to this one so it can serve as the canonical policy.

As a new contributor, I want to be able to easily determine what are the goals of the project, what is the long-term direction of the project, and what is actively being worked on.

To solve the first two, I propose we more heavily utilize the roadmap feature on Github to track goals for cosign, fulcio and rekor. We should also schedule periodic triaging of open tickets.

Context: New contributor friction log

Following on from the logo refresh work done in #55 this issue tracks the follow up work, which is:

• update the brand guidelines to match the new logo (https://github.com/sigstore/community/blob/main/artwork/Sigstore_Guidelines_2021.pdf)
• update the subproject logos to be more in keeping with the new logo

This issue tracks a request to Linux Foundation creative team for a refresh of the logos for Sigstore

(https://sigstore.slack.com/archives/C01D0PA9QKF/p1644000736824899)

@dlorenc , I might need you to do this or you see if you can raise my priv to administrator

https://support.google.com/a/answer/1626902?hl=en

I was just thinking, is there anyone at tektoncd we could chat to and get some invite into how they have things set up?

I think the vast majority, if not all, dependabot PRs are merged once tests pass. This is manual, and while it's not that much of a burden, I think we can automate this. See https://docs.github.com/en/code-security/dependabot/working-with-dependabot/automating-dependabot-with-github-actions#enable-auto-merge-on-a-pull-request for instructions on how to set this up.

When there's a major Go version update, I think we have to do something manually too, so maybe we don't merge those automatically.

I'm also not sure if we would need to update tests that are required for each repo, or if branch protection should limit merging if any test, required or not, fails.

I'd suggest this be enabled for the larger repos (Rekor, Fulcio, Cosign), and for others, maintainers can decide if they want to enable it or not.

cc @cpanato - Thoughts?

TAC and and community meetings get recorded , so others can watch later (especially if in a different TZ)

Over time the sigstore community will create research. An example is the current projectsbyIF work. This research may be useful for the current and future sigstore communities.

Creating a /community/research/ folder will provide a simple, initial mechanism for storing and providing access to research.

A first entry could be the projectsbyIF research insights document:

[external] sigstore discovery – research insights.pdf

(To reduce effort for others I would connect this issue to a PR with proposed changes but don't have the github rights :))

The community chair position is now open for nominees. Contributors (commits or issues raised / past attendance to the community meetings) who are active in sigstore can self nominate. please drop you name below, with a quick bio and why you think you would be suited for the role.

From sigstore/sigstore#305:

@lukehinds:

We don't have anything defined as each project has autonomy to manage its own maintainers (codeowners).

As a general guide, I myself view a maintainer as someone who regularly helps review code, finds and resolves bugs and adds features. A good candidate is someone who has a consistent presence in the project.

I hope that helps and sorry for not being more specific. Currently a lot of your contributions (of a varied type) are towards cosign, so that looks like a good trajectory towards being a maintainer.

@dlorenc:

I kind of miss having something like peribolos to manage permissions across an org, but don't really want to have to setup prow just for that. @cpanato do you know of any way to do that easier?

cc: @cpanato @naveensrinivasan

• To perform any automation/tasks that we as humans will not do with our own account

/assign @cpanato

Action required if your name is below and you'd like to keep access to Cosign.

Hey all,

We've managed to accumulate quite a few cosign-codeowners:

• @Dentrax
• @asraa
• @bobcallaway
• @dekkagaijin
• @developer-guy
• @dlorenc
• @font
• @hectorj2f
• @loosebazooka
• @luhring
• @lukehinds
• @mattmoor
• @n3wscott
• @priyawadhwa
• @vaikas
• @znewman01

This makes it hard to make changes that we'd want every owner's consent for (for example, sigstore/cosign#2519 ).

Let's tidy up. I'm going to remove anybody who no longer can prioritize maintaining Cosign. If you'd like to stay on as a Cosign codeowner, please 👍 this comment by this time next week, Monday Jan 16th. (If you happen to miss it after we clean up I'm happy to add you back.)

I believe the Linux Foundation has drafted some suggested language for Terms of Use for the public Sigstore infrastructure.

Once the drafted has been reviewed and posted at a public URL, we can link to it as we work on things like npm supports creating verifiable links between a package version and its source/build - Public beta.

I have a quick request, and have no idea if this is possible with Pulumi.

Adding new CI workflows, or changing the required status checks, currently requires maintainers to make a PR in sigstore/community. Is it possible for the stub of the config on status checks to live in the individual repositories?

Once branch protection is set in this one, then it should be safe for the individual repositories to commit the configuration for status checks in their own repositories.

@cpanato maybe you might know?

Multiple reviewers can help for a number of reasons:

• Provide a different perspective
• Reduce the impact of single account compromise

This can be enforced by Github

This has also been brought up on Fulcio - sigstore/fulcio#374 @nsmith5

Context: New contributor friction log

Code changes should be accompanied with tests. This may include unit tests or end-to-end tests. I propose that we enforce a minimum code coverage percentage. This can be enforced by a presubmit check. I assume that unit test coverage will directly contribute to the code coverage percentage. We will need to investigate how best to enforce adding end-to-end tests for larger features.

Context: New contributor friction log

#49 prompted the thought that we should consider pursing SLSA compliance

As mentioned by @priyawadhwa at the sigstore oncall meeting:

https://github.com/sigstore/community/actions/runs/3175965606

[Update](https://github.com/sigstore/community/actions/runs/3175965606/jobs/5174727890#step:11:151)
code: 255
 stdout: Updating (sigstore/github-prod)

View Live: https://app.pulumi.com/sigstore/sigstore-github-sync/github-prod/updates/225

@ Updating.....
  pulumi:pulumi:Stack: (same)
    [urn=urn:pulumi:github-prod::sigstore-github-sync::pulumi:pulumi:Stack::sigstore-github-sync-github-prod]
    ~ github:index/teamRepository:TeamRepository: (update)
        [id=6693572:helm-charts]
        [urn=urn:pulumi:github-prod::sigstore-github-sync::github:index/teamRepository:TeamRepository::helm-charts-sigstore-oncall]
      ~ permission: "push" => "write"
        repository: "helm-charts"
        teamId    : "6693572"
Resources:
    309 unchanged

Duration: 57s

 stderr: error: 1 error occurred:
	* updating urn:pulumi:github-prod::sigstore-github-sync::github:index/teamRepository:TeamRepository::helm-charts-sigstore-oncall: PUT https://api.github.com/organizations/71096353/team/6693572/repos/sigstore/helm-charts: 422 Validation Failed []


error: update failed

 err?:

As a new contributor, I want to track what is actively being worked on so that I can find new issues to implement. Due to access restrictions around assignment of issues, individual contributors cannot self-assign issues.

At a bare minimum, I propose that we update community guidelines to ask contributors to comment on an issue when they're actively developing. If a developer cannot complete a feature, they should update the issue so that another contributor can work on it.

I propose that we also investigate tooling around self-assignment of issues.

Context: New contributor friction log

We are looking to improve our documentation and a new docs site will be launched. We would also really benefit from translations as well.

If you can help in anyway at all, please tag yourself in a comment below

Hey All,

This is a tracking bug for the overall sigstore public key ceremony, which we'll use to establish a TUF trust-root for all sigstore signing. The design for that kicked off here: sigstore/fulcio#12 but grew a bit bigger in scope. The latest document describing the overall strategy is here: https://docs.google.com/document/d/1dJ5JNyLcuB6Fbl7eV5Rx8xlXdgic2thMFSseq4Y-pRo/edit?resourcekey=0-amsoXrePIvR2244GSTxeOw

@asraa is driving the initial implementation, and the first 5 "key holders" will be:

• @lukehinds
• @dlorenc
• @SantiagoTorres
• @mnm678
• @bobcallaway

We're targeting a "practice run" sometime the week of the May 17th 2021, and then (hopefully) the "real event" will take place during the following week (the week of May 24th).

Stay tuned for more information and scheduling!

Description

Define release cadence for :

• rekor
• cosign
• fulcio
• sigstore

with that we can publish the expected release dates for the community and also we can track the PR/Issues that we can include in the release.

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.