Description

I wanted to use Google KMS instead of generating keys using cosign, and for testing purposes I just used an old key of type 4096 bit RSA key PSS Padding - SHA256 Digest. This returned the following error: main.go:74: error during command execution: signing [[IMAGE@sha256:DIGEST](http://IMAGE@DIGEST)]: signing digest: [POST /api/v1/log/entries][400] createLogEntryBadRequest &{Code:400 Message:error processing entry: verifying signature: crypto/rsa: verification error}. I used the Elliptic Curve P-256 keySHA256 Digest type in Google KMS instead, which worked fine.

I think documentation regarding which kind of keys are allowed for signing should be improved, because this was not entirely obvious. I could only find cosign differs in that it signs with ECDSA-P256 keys instead of PGP, and stores signatures in the registry. in the FAQ, which is why I tried that type of key, but looking in the FAQ was not my first choice.

Hello,
On this web page policy-controller/overview, I noticed a bad link installation instructions (error page not found).

The markdown file with the bad link is this one:

I don't know for sure, but the link should probably point toward content/en/policy-controller/installation.md.

Description

It seems that the signing/verification method of your artifacts was changed and the instructions document is not aligned with it.

In the past v0.3.0 and earlier, you used to publish a certificate file alongside the main artifact and its signature file (like the example in the doc rekor-cli-linux-amd64_cert.pem).
Since then, the signing methods changed, and the artifacts are now published with another file with the suffix -keyless.pem or -keyless.sig.

It's not clear how the artifact should now be verified.

Links to the document
verify-release.md
Website

Description

Copied (in part) from #94 in sigstore/sigstore-website

We could add some code samples (or links to other repos that contain them) for sigstore/sigstore for signing

Description

Read through sigstore docs with SME and implement changes requested.

Hayden recommended that we remove the "kubernetes" page from the sigstore docs.

cc @jonvnadelberg @haydentherapper

Including:

• Use cases
• Payload (as described here)
• How to correlate SET with <--> UUID of entry

Basically a post walking someone through this for a Rekor entry.

Slack convo ref

The current quick start guide contains some information that needs updating. Doc should be rewritten so it is more relevant to user's needs.

Description

In some site previews, an old Sigstore image is being pulled.

Slack:

Twiiter:

Description

Copied (in part) from #94 in sigstore/sigstore-website

We could add some code samples (or links to other repos that contain them) for the rekor client

There are a couple of policy examples in the policy-controller docs that use cue policies, but I can't find any documentation that specifically address CUE and Rego support and how it works.

• Here's how to craft a CUE policy, here is the spec/language reference
• Here's how Rego policies work, here is the reference on how they need to be written (including custom error messages)

What happens if a Fulcio/Rekor key is compromised? We have a proposed plan, but it's not documented on the web site.

There are two reasons we might want to do this:

1. Helping folks deploy private instances. This can be seen as an extension to the Cosign with Custom Components page, and possibly warrants its own issue/effort.
2. Transparency, and generally inspiring confidence in our security protocols.

A very first attempt at this might just say:

Because we distribute the key material for Sigstore services (Rekor and Fulcio) via The Update Framework(TUF), revocation is very easy. We currently keep all rotated Rekor/Fulcio keys in the repository (per the Log Verification with Expired Targets proposal; you may need to join [email protected] for access). Then, to revoke a key, we just need to remove it from the TUF repository! Sigstore clients will stop trusting it immediately.

The document Revocation of untrusted TUF targets; you may need to join [email protected] for access) proposes adding a revocation list so that Sigstore clients can recognize when a key is revoked and report this to end users accordingly to make it easier to understand what's going on, but the above revocation plan is sufficient for security.

Description

The markdown contents inside the Detailed Gitsign Usage page is overflowing outside of the container.

Screenshots 👇🏼

Inspectable at gitsign/usage

Additionally, I've tested it locally on both big screens and mobile devices, checks out that the issue is reproducible & valid for both. ⬇️

Big-Screen 🖥️	Small-Screen 📱

with the only exception being medium screen devices (iPad, Tablets etc.) 👇🏼

• I am currently working on this but it's open to collaborators & as always, suggestions & feedback are always welcome! I'll keep posting updates & create a PR once resolved.
  cc: @ltagliaferri, @cpanato

OS : Ubuntu (22.04 LTS, x64)   /   Windows 10 Pro (x64)
Browser : Google Chrome — Version 111.0.5563.147 (Official Build) (64-bit)

Description

We support some integrations with cloud providers, but they aren't really listed anywhere. Things like KMS, CA APIs, and keyless/oidc support bridge across individual tools (fulcio/cosign), so there's no great spot today.

Bundle under a "Sigstore on cloud providers" section.

Build system integrations would be good too!

The OID Information link here:

From a quick search, I don't see where this should currently be pointed to.

Description

Most users nowadays prefer surfing docs with Dark-Mode enabled. But, in the current design, the user has to first scroll down to the bottom & then can access the toggle button to switch between themes, which I believe is a bad UX.

Solution

I propose a solution where we can shift the button to the sticky navbar which will remain fixed even if we scroll down, so that the user can switch between themes anytime they want. Plus, we can also shift the "Built with Nuxt" promo to the sidebar to make to reduce unnecessary space wastage on the viewport.

Final look 👇🏼

P.S. : If this issue is validated & approved, I'd love to contribute. Additionally, I do have a similar design in mind, following the same approach for responsive mode (i.e. mobile view).

Description

cosign attest --help lists a --type parameter but it is not clear what values this parameter can accept. It seems it is not required but would be good to know what is the purpose of the parameter and what values are accepted. Adding documentation to the following page may be good https://docs.sigstore.dev/cosign/attestation

Description

Cosign is the tool used to verify signatures but for the first installation of Cosign there is no way to verify the downloaded/installed binaries. Documentation similar to https://docs.sigstore.dev/rekor/verify-release would be helpful for people who install Cosign for the first time.

Graphviz which I found quite helpful in understanding the relationship between Sigstore and Trillian: (graphviz source)

I bet this would be a good contribution to the dev docs.

Reference for "trillian API": https://github.com/google/trillian/blob/master/trillian_log_api.proto

Originally reported by @znewman01 in #169 of sigstore/sigstore-website

Currently, when you clone this repository as a fresh project and run a yarn dev (after the yarn install), you get the Error: error:0308010C:digital envelope routines::unsupported error if you are running Node v17. We should probably add a little note in the README detailing that Node v16 is required. Saves troubleshooting time of new contributors?

Description

Documentation has a small spelling mistake here. I'm making this issue to link the PR I'm logging now.

Resolution

Resolution is simple, it's just updating the word that is mistyped from gGtsign to Gitsign.

I realise that according to the comment on the PR template I am supposed to allow time to discuss, but given the nature of this (being a simple spelling mistake), I am going to submit the PR straight away.

Description

I recently encountered a critical bug in the sigstore docs that causes the website to break or freeze. This issue specifically affects the search functionality, which is a crucial tool for navigating the docs. Upon attempting to perform a search for the second time using the search bar, the entire docs page becomes unresponsive and no further actions can be taken.

To reproduce follow these steps:

1. Visit https://docs.sigstore.dev
2. Search for any keyword, say — "Custom Components" (from Configuring Cosign with Custom Components) [present in Cosign section]
3. It should return a list of suggestions (not sorted, but it's okay)
4. Select the option & it should be fine till now.
5. Go back to the home of docs page (in the same tab) i.e. https://docs.sigstore.dev (either by editing the current URL or simply by clicking the Sigstore logo on the top right)
6. NOW, Search something (perform a keyword search just like the previous time)
7. Say, search for this — "Other Types" (from Signing and Uploading Other Types) [present in the Rekor section]
8. Now notice, it isn't returning anything and simply suggesting a few topics from Cosign (whereas it should suggest from the Rekor section)

Now the main part, you'll clearly notice, when you have typed around 3-5 characters in the search bar, it returns a TypeError 'key' read error, which essentially freezes the inner bundle code.

BOOM! 💥 The page freezes, & everything becomes constant, nothing works, not even clicking!

cc: @ltagliaferri, @cpanato  

⚠️ Note that the search function is not case-sensitive & the only way it can be fixed is by simply performing a fresh reload of the page.

OS : Ubuntu (22.04 LTS, x64)   /   Windows 10 Pro (x64)
Browser : Google Chrome — Version 111.0.5563.147 (Official Build) (64-bit)

Description

Current build instructions result in an error and build fails. Also make some text changes in docs as requested by eng.

Version

Node.js version 19.8.1 fails in yarn

Description

Rekor installation docs claim that:

There are a few ways you can deploy a Rekor Server:

1. We have a docker-compose file available
2. A kubernetes operator
3. Alternatively, you can build a Rekor server yourself.

I believe this is misleading as the operator does nothing and can't be used to install Rekor. There for I recommend removing point number 2 from the list mentioned above.

Version

main

Description

Copied from #152 in sigstore/sigstore-website

Currently, the docs shown on the sigstore.dev website are of the latest iteration of the docs only.
It would be nice and probably correct to have a version selector if users are using an older version.

Original request: DennyHoang

It would be great to have a quick and easy guide on this topic, including:

• Use of the API vs. TUF
• Locations of keys and certs
• Keys per shard/log in Rekor
• Commands to use to very the pubkey(s) (openssl, etc.)
• Verifying pubkey back up to the TUF community trust root (linking to article about how that root works wrt Sigstore/Rekor)

From @haydentherapper : "We should document that for the public deployment, the API should not be used to verify entries, that the keys should come from TUF. For private deployments, TUF is recommended but if you do choose to use the API, you should at least do trust-on-first-use." Slack convo ref

We get a lot of questions about air-gapped deployments for Cosign, policy-controller, etc. There are a fair number of important considerations: getting TUF roots across, etc.

Worth writing up once and for all.

CC @clemenko @vaikias

Description

We support some integrations with cloud providers, but they aren't really listed anywhere. Things like KMS, CA APIs, and keyless/oidc support bridge across individual tools (fulcio/cosign), so there's no great spot today.

Bundle under a "Sigstore on cloud providers" section.

Build system integrations would be good too!

Description

#94 removed documentation for the COSIGN_PASSWORD environment variable. This is useful documentation that should go somewhere.

@jonvnadelberg @ltagliaferri

Description

The current signing documentation is not organized to be easily read by users, and should be updated to make it more accessible.

Including:

• Chaining of roots
• How to check which community keys are "current" on the root
• Summaries of videos/key ceremonies
• How the rotation works for Rekor/Sigstore specifically so that you know when to trust it without having to know all about TUF

Edit: how/whether cosign and rekor handle TUF key rotations the same way or differently. How to set this up on private instance of Rekor.

Slack convo ref

Description

The Cosign binary is signed both with keyless signing and an artifact key. You first need to verify Cosign with the artifact key, since you will need Cosign to verify the keyless signature.

https://github.com/sigstore/fulcio/pull/1079/files#diff-b335630551682c19a781afebcf4d07bf978fb1f8ac04c6bf87428ed5106870f5R78 includes instructions for Fulcio. This should be copied over for verifying Cosign binaries.

Description

I found a similar paragraph used in most of the overview pages of various sigstore tools. The paragraph is a call to action for users to join the slack community of each tool. The paragraph can be rewritten in some instances, but for the 'Getting Started' section on the cosign overview page, I think it should be removed as the purpose of a getting started section is to provide clear instructions on how to install and use cosign which I believe is already covered in the installation page of cosign.

Also, I noticed that the overview page isn't giving an overview into cosign in comparison to other overview pages of each sigstore tool that gives a somewhat description of the tool.

Proposed Changes;

1. Rewrite the similar paragraph across all overview pages.
2. Remove the 'getting started section' on the overview page of the cosign tool
3. Rewrite the overview page of the cosign tool to be consistent with the overview pages of other tools, by actually giving an insight into cosign.

Attached below, is a screenshot of the recurring paragraph;

Description

The top navbar GitHub icon os pointing to the sigstore/sigstore-website repo URL despite it being updated in the config file.

See sigstore/cosign#2416

This page should mention GITLAB_HOST: https://docs.sigstore.dev/cosign/git_support

Also might be nice to have a page where we document all the env vars (a la cosign env).

This issue was automatically created by Allstar.

Security Policy Violation
No protection found 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.

Description

in the first paragraph of Home page, while introducing Sigstore there is a sentence stating: Signing materials are then stored in a tamper-resistant public log.

Shouldn’t that be: Signed materials are then stored in a tamper-resistant public log.?

Version

Description

Here I found one sentence which is jumbled and not creating any sense

Current behaviour

This checks you are who you say you are using OpenID Connect

if we update with this might be meaningful

This checks who you are using OpenID Connect

Description

We support some integrations with cloud providers, but they aren't really listed anywhere. Things like KMS, CA APIs, and keyless/oidc support bridge across individual tools (fulcio/cosign), so there's no great spot today.

Bundle under a "Sigstore on cloud providers" section.

Build system integrations would be good too!

Description

Some key management systems may default to RSA type keys. We should add a note to https://docs.sigstore.dev/cosign/key-generation that RSA keys are not supported.

The beginnings of this exist already:

• https://docs.sigstore.dev/cosign/custom_components
• #19

But I propose the following reorganization:

• Run your own Sigstore
  • Overview
  • Scaffolding
  • Managing keys with TUF (this would mostly pull from "Configuring Cosign with Custom Components")
    • TUF
    • Revocations (#19)

This should eliminate most of "Configuring Cosign with Custom Components," so we could drop that page and make it an FAQ.

Description

Copied (in part) from #94 in sigstore/sigstore-website

We could add some code samples (or links to other repos that contain them) for the fulcio client

This may seem like a small point, but it is not completely clear that you can do this, and it greatly simplifies some workflows to not have to do it.

Description

Copied from #84 in sigstore/sigstore-website

We all know to cosign is excellent. So IMHO, we should support documentation about how people who might want o use it in their tooling can use cosign as a Go module which can help us increase tooling around cosign. Again IMHO, we should provide two samples, one for how to use cosign with public/private key pairs, latter is Keyless mode.

Original request: @developer-guy

Description

Copied (in part) from #94 in sigstore/sigstore-website

We could add some code samples (or links to other repos that contain them) for Cosign as an API/SDK

There is an issue where users are reporting landing on older versions of the docs site and need to hard reset multiple times. I have cleared and re-deployed the Netlify cache but this did not address the issue.

Especially wrt the updates after sharding. I have gotten questions around this.

Description

Version

https://docs.sigstore.dev/cosign/working_with_blobs#sget

github.com/sigstore/cosign/cmd/sget was deprecated, so sget outputs the following notice.

$ go install github.com/sigstore/cosign/cmd/sget@latest
$ sget --help
main.go:43:
-------- NOTICE --------
The sget tool in the cosign repo is deprecated, and will be removed in a future release.

If you're interested in fetching content from an OCI registry or from an arbitrary URLs, please see: https://github.com/sigstore/sget.
------------------------
sget is DEPRECATED in the cosign repo -- see https://github.com/sigstore/sget for the new tool.

The correct Module path is github.com/sigstore/sget@latest.

$ go install github.com/sigstore/sget@latest

Side bar view of docs.sigstore.dev in browser:

View in incognito:

If I were to guess, page caching is too long-lived. Is this something that is controllable?