Set the user agent to sigstore-js-<version> for usage monitoring.

Description

The Fulcio V1 API will be turned down in the coming months.

https://github.com/sigstore/sigstore-js/blob/main/src/client/fulcio.ts#L55 will need to be updated to https://github.com/sigstore/fulcio/blob/main/fulcio.proto#L65. We support either gRPC or HTTP.

Description

Currently, the only Rekor entry type which can be created is "hashedrekord" (even when signing an intoto-style provenance attestation). The signing logic should be updated to support both "hashedrekord" entries (for blob signing) and "intoto" entries (for intoto attestations). In the future this should probably expand to include all the various Rekor entry kinds, but these two are the most relevant for our current use cases.

Description

The usage example at https://github.com/sigstore/sigstore-js/tree/main/packages/sign has the following snippet:

// Sign a thing
const artifact = {
  data: Buffer.from('something to be signed'),
};
const bundle = await bundler.create(artifact);

However, this will not work as the example sets up a DSSEBundleBuilder which requires the type key to be set on the artifact. Perhaps this example will need to be updated to have type: 'dsse_envelope' added to the artifact

Version

2.0.0 from NPM

Description

It seems like both versions 1.0.1 and 1.0.2 were not successfully published to the npm repo.

npm ERR! code ETARGET
npm ERR! notarget No matching version found for @sigstore/tuf@^1.0.1.
npm ERR! notarget In most cases you or one of your dependencies are requesting
npm ERR! notarget a package version that doesn't exist.

Describe the issue
When running a workflow that utilizes sigstore-js to generate a token I received the error messages: "error creating signing certificate" and "error creating tlog entry". Running the workflow again after the first two failures resulted in it generating the token successfully, but I am still confused as to the exact reason why it failed the first two times. To help users identify the source of their problem, I propose improving error messages to provide more detail about the specific issue or failure that occurred. This will give users a better understanding of what went wrong and why, which will make it easier for them to troubleshoot the problem and understand why it occurred.

Relevant Links
Code for "error creating signing certificate"
Code for "error creating tlog entry"

Context if Needed
These were my workflow runs:
Run 1: "error creating tlog entry"
Run 2: "error creating signing certificate"

Description

Part of the verification workflow should include verifying the Rekor entry. This should include support for both the offline case (where a rekor bundle is provided) and the online case (where the rekor bundle is looked-up in the transparency log).

Essentially, need to mimic the logic implemented in cosign here.

Description

This has not been rolled out into the production sigstore environment yet, but it is available in staging (rekor.sigstage.dev).

sigstore/rekor#1487 added support for a new pluggable type dsse which has the following benefits:

• The JSON schema more clearly separates the proposed entry from what is persisted to simplify client expectations
• The DSSE envelope is provided as a JSON string, rather than double-encoding values in base64
• The DSSE envelope is not stored by Rekor; this is to set the client expectation that attestation storage in Rekor should not be relied upon for attestation discovery.

Generally sigstore-xx code repositories are libraries. What are you thoughts on having a generic library and then a repository for an NPM signing CLI (which consumes from the library)

I ask as I am building something similar in typescript and it would be useful to be able to not have to duplicate a lot of what you have here (get OIDC token, call fulio/rekor, generate keys etc).

I realise you have important fish to fry getting npm on-board and its not likely a good time to refactor, but I figure we can at least kick the tyres over the idea.

Description

The current verification workflow accept an optional signing certificate parameter. If the certificate is not provided, it is looked-up in Rekor by searching for an entry with a matching hash. This is not recommended -- the certificate should be a required parameter for the verification workflow.

The conformance test action now supports testing against Sigstore staging infrastructure. Testing against staging is beneficial because

• when infrastructures changes, it happens first in staging: finding out ASAP is good for clients
• as a practical example: The staging TUF metadata has recently changed because of new tooling. Similar changes will happen in production infra in the future.

Enabling the support requires two things:

1. A new argument --staging needs to be added to commands in sigstore-js/packages/conformance/src/commands/ (see CLI protocol): when the flag is present, client should use staging services
2. New call should be added to conformance.yml as described in README

Missing documentation for @sigstore/CLI token command.
README has no mention of this command or its working.

Description
Keeping getting an error:
Failed to notarize the asset: TypeError [ERR_INVALID_ARG_TYPE]: The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received undefined.

Tried passing strings and json bodys too. Currently using this
const assetBuffer = Buffer.from(
JSON.stringify(assetEnvelope),
'utf-8'
)

Using Sigstore-js latest version, same issue with @sigstore.sign

I'd like to make use of sigstore bundle validation in the npm CLI but it doesn't appear there are any currently exported methods to do that.

I suppose simply calling verify would do roughly the same thing but I'd like to be able to validate the format of sigstore bundles without necessarily verifying the signatures, querying Rekor, etc.

Description

I think a typical use case will be a project that has N people who are authorized to sign artifacts (releasers in the case of the Node.js project - https://github.com/nodejs/node#release-keys) and the end user wants to be able to easily validate that one of those people have signed an artifact.

I think in the simplest flow where ephemeral keys have been used (which I think is really nice in that certificates don't have to be stored/managed), the equivalent is that the user will want to verify that the artifact has been signed by any one of a list of emails.

sigstore-python has the option -cert-email but that only validates against a single email which does not quite fit this use case. Instead something like a --cert-emails that allows you to provide a list or file containing a list of emails would simplify the verification.

Question

• signstore Whether to support npm embedded signatures，if suported it,How do I manage signatures and artifacts if I separate signatures

I get this error when using the library and ncc to compile my project: ::error::Cannot find module '../../store/public-good-instance-root.json'

Problem with tuf-js?

Any pointers? happy to send a PR, but I'm not sure where this file is looked up.

Description

@sigstore/tuf contains a require.resolve for seeds.json that can easily be replace with a require which can be parsed by bundlers targeting server-less environments.

npm/cli#4291

@sigstore/tuf contains one of the blocking require.resolve for @npmcli/arborist to be bundable.

Description

https://github.com/ossf/scorecard

Notes on stabilising the CLI/library interface:

• Cosign and sigstore-python both use rekor-url and fulcio-url as option names for the base url, whereas we currently use rekor/fulcio-base-url
  • Suggestion: update to use --rekor-url/rekorUrl, --fulcio-url/fulcioUrl in CLI params and sign method params
• CLI exposes signDSSE whereas the underlying method is called signAttestation
  • Suggestion: Update CLI and library method to attest
• Sigstore.utils currently exports createDSSEEnvelope and createRekorEntry
  • Should we explicitly mark these interfaces as "experimental" interfaces giving us the freedom to do breaking changes without major version bump?
• verify exposes a tufRootPath option but we don't seem to use it anywhere yet?
  • Suggestion: remove this option until someone asks for it and maybe there's clear guidance from the sigstore tuf 2.0 spec?
  • It looks like the draft sigstore tuf client doc suggests setting this with a env var TUF_ROOT and it seems like cosign already supports this.

Description

For the Golang library, we embed a copy of the target files, and check if the target file matches the target metadata here (a necessary check since the target file may have been updated and would need to be downloaded). Would it be possible to do the same for sigstore-js?

Toying with some ideas for refactoring the signing workflow in sigstore-js . . .

Considerations

So, you want to use Sigtore to sign a thing . . . I have some questions?

How do you want the signature to be packaged?

Do you want a naked signature, or would you like it packaged into a DSSE envelope along with the artifact being signed? The answer to this question obviously influences the returned format of the signature, but also (less intuitively) has implications for how the artifact needs to be prepared before the signature can be generated (see PAE for DSSE).

What sort of keypair are you going to use to generate the signature?

Are you providing your own key or using a KMS to do the signing? Do you want to use the Sigstore "keyless" approach with a certificate issued by Fulcio?

Which entities do you want to witness the generated signature?

Are you going to send the signature to the Rekor transparency log and bundle the SET with your signature? Maybe you want to send your signature to multiple Rekor instances? Are you going to generate a signed timestamp and bundle that with your signature? Perhaps you want to use both Rekor and a Timestamp Authority?

Models

Signatory

Responsible for generating the signature over the provided data. Returns an Endorsement which is a signature and the public key which can be used to verify that signature.

classDiagram
    class Signature{
        byte[] signature
        string key
    }
    class Signer
    <<interface>> Signer
    Signer : +sign(data) Signature

    class KeylessSigner {
        FulcioClient fulcio
        IdentityProvider provider
        +sign(data) Signature
    }

    class KMSSigner {
        KMSClient kms
        +sign(data) Signature
    }

    Signer <|-- KeylessSigner : implements
    Signer <|-- KMSSigner : implements

Witness

Some entity which can provide a counter-signature over the Signatory's endorsement.

classDiagram

    class VerificationMaterial {
      TLogEntry[] tlogEntries
      Timestamp[] timestamps
    }

    class Witness
    <<interface>> Witness
    Witness : +testify(signature) VerificationMaterial

    class TSAWitness {
        TimestampAuthorityClient tsa
        +testify(signature) VerificationMaterial
    }

    class RekorWitness {
        TLogClient tlog
        +testify(signature) VerificationMaterial
    }
    Witness <|-- TSAWitness : implements
    Witness <|-- RekorWitness : implements

BundleBuilder

Implements the overall workflow of signing an artifact and packaging the result. Is configured with a single Signer and a list of Witness implementations. The BundleBuilder invokes the Signer to generate a signature and then passes the result to each of the configured Witness instances. The returned Signature and VerificationMaterials is packaged into a Sigstore Bundle.

classDiagram
class BundleBuilder {
      <<interface>>
      create(artifact) Bundle
    }

    class BaseBundleBuilder {
        <<abstract>>
        Signer signer
        Witness[] witnesses
        +create(artifact) Bundle
        #prepare(artifact) Buffer
        #package(signature)* Bundle
    }
       class Signer
    <<interface>> Signer
    Signer : +sign(data) Signature
    class Witness
    <<interface>> Witness
    Witness : +testify(signature) VerificationMaterial

BundleBuilder <|-- BaseBundleBuilder : implements
     BaseBundleBuilder o-- "1" Signer
     BaseBundleBuilder o-- "0..n" Witness

Specializations of the BaseBundleBuilder are responsible for packaging the signature and verification materials into the appropriate bundle format:

• MessageSignatureBundleBuilder - Combines everything into a "messageSignature"-style Sigstore bundle
• DSSEBundleBuilder - Combines everything into a "dsseEnvelope"-style Sigstore bundle. This includes an implementation of the .prepare method in order to perform the DSSE-specific pre-authentication encoding before passing the artifact to the Signatory.

classDiagram
    class BaseBundleBuilder {
        <<abstract>>
        Signer signer
        Witness[] witnesses
        +create(artifact) Bundle
        #prepare(artifact) Buffer
        #package(signature)* Bundle
    }
    
    class MessageSignatureBundleBuilder {
        #package(signature) Bundle
    }

    class DSSEBundleBuilder {
        #prepare(artifact) Buffer
        #package(signature) Bundle
    }   

        BaseBundleBuilder <|-- MessageSignatureBundleBuilder : extends
    BaseBundleBuilder <|-- DSSEBundleBuilder : extends

Description

similar issue : random callback uri port · sigstore/cosign sigstore/cosign#1105

workaround

#!/bin/sh
FOO_CONTAINER=foo1234

docker build -t $FOO_CONTAINER - <<'EOF'
FROM node:18.14-alpine3.17
RUN apk add --no-cache jq openssl curl coreutils
WORKDIR /app
RUN npm install [email protected]
EOF

docker run -i --rm -p 18089:18089 --entrypoint=sh $FOO_CONTAINER <<'EOF'
npm version
# Added environment variable for OIDC callback port and turn xdg-open to echo
cd /app/node_modules/sigstore/dist/identity/
sed -i.bak 's/listen(0/listen(Number(process.env.OIDC_CALLBACK_PORT) || 0/ ; s/xdg-open/echo/' oauth.js
diff oauth.js.bak oauth.js
cd /app
echo "content to be signed" > artifact
export OIDC_CALLBACK_PORT=18089
npx sigstore sign artifact > bundle.sigstore
cat bundle.sigstore | jq
cat bundle.sigstore | \
  jq --raw-output '.verificationMaterial.x509CertificateChain.certificates[0].rawBytes' | \
  base64 -d | openssl x509 -inform der -text
LOGINDEX=`cat bundle.sigstore | jq --raw-output .verificationMaterial.tlogEntries[0].logIndex`
curl -s https://rekor.sigstore.dev//api/v1/log/entries?logIndex=$LOGINDEX | jq --raw-output '.[].body' | \
  base64 --decode | jq
npx sigstore verify bundle.sigstore artifact
EOF

diff output

--- oauth.js.bak
+++ oauth.js
@@ -45,7 +45,7 @@
         const sockets = new Set();
         // Start server and wait till it is listening
         await new Promise((resolve) => {
-            server.listen(0, resolve);
+            server.listen(Number(process.env.OIDC_REDIRECT_PORT) || 0, resolve);
         });
         // Keep track of connections to the server so we can force a shutdown
         server.on('connection', (socket) => {
@@ -160,7 +160,7 @@
                     open = 'open';
                     break;
                 case 'linux' || 'freebsd' || 'netbsd' || 'openbsd':
-                    open = 'xdg-open';
+                    open = 'echo';
                     break;
                 case 'win32':
                     open = 'start';

related code

• sigstore-js/src/identity/oauth.ts

  Lines 51 to 59 in a434d60

  	private async initiateAuthRequest(): Promise<string> {
  	const server = http.createServer();
  	const sockets = new Set<Socket>();
  	// Start server and wait till it is listening
  	await new Promise<void>((resolve) => {
  	server.listen(0, resolve);
  	});

• sigstore-js/src/identity/oauth.ts

  Lines 193 to 207 in a434d60

  	case 'linux' || 'freebsd' || 'netbsd' || 'openbsd':
  	open = 'xdg-open';
  	break;
  	case 'win32':
  	open = 'start';
  	command = `"" ${command}`;
  	break;
  	default:
  	return reject(`OAuth: unsupported platform: ${process.platform}`);
  	}
  	console.error(`Your browser will now be opened to: ${url}`);
  	child_process.exec(`${open} ${command}`, undefined, (err) => {
  	if (err) {
  	reject(err);
  	} else {

I think that due to this line, when invoking verify outside the CLI with sigstore as a library, this attempts to fetch the rekor.pub from the caller's dir:
Error: ENOENT: no such file or directory, open '/home/runner/work/_actions/laurentsimon/slsa-delegator/main/actions/store/rekor.pub'

Is there some way to reference the module path? I think I can just get around this by supplying my custom path into my node_modules, but just wanted to flag.

Description
Hi! In slsa-github-generator, we use Sigstore to generate and verify our signing tokens. Our workflows were working with Sigstore v1.8, however, when we upgraded to v1.9, we experienced issues with the generation and verification of the signing tokens. We were curious if this backwards incompatibility was intentional or not.

The first issue for us lies within the sign function. In this workflow, we see that in v1.9, our sigstore.sign function fails, not identifying that it is in a GHA workflow.

However, the attest function also has the same issue. In this workflow run, we use v1.8 version of sign but use the v1.9 version of sigstore.attest, and have the same issue of the not identifying that it is in a GHA workflow on a later job.

Is this functionality the intended behavior? Thank you!

Version
Issues with Sigstore v1.9
Expected behavior with Sigstore v1.8

In the Sigstore clients special interest group meeting today, we discussed an issue with the release signatures on CPython.

We have two recommendations for client libraries:

1. After signing, the clients MUST verify the signature (see Sigstore client spec). 2.
2. Client library interfaces SHOULD allow callers to specify an identity (and other verification parameters) to use for this verification.

I'm going to be a bit lazy (sorry) and rather than inspecting every client library by hand, just ask whether you're doing the these and, if not, whether you all agree with these recommendations.

Description
Based on the feedback we've received and the lessons we've learned from integrating this library into the npm CLI and registry, we have a number of big changes we'd like to make. We're currently working toward a 2.0 release of the main sigstore client which will contain breaking changes to the public interface:

• Removal of the basic CLI shipped as part of the sigstore package. This CLI was only ever intended to be a demo/testing tool and has been superseded by the far more robust CLI now found in the @sigstore/cli package.

• Removal of the TUF-related tuf.getTarget and tuf.client functions from the public interface of the sigstore package. All of the functions related to interaction with the Sigstore TUF repository have been moved to the @sigstore/tuf package.

• Removal of the following OIDC-related options from the public sign and attest functions:

  • oidcIssuer
  • oidcClientID
  • oidcClientSecret
  • oidcRedirectURL

  These options all relate to the OAuth identity provider used to retrieve an OIDC token through interactive user authentication. The code supporting interactive authentication has been moved to the CLI (@sigstore/cli) and will be removed from the main sigstore package. Each of these options is exposed as a command line flag on the CLI's attest command.

• Removal of the signer option from the public sign and attest functions. The bring-your-own-signer use case will be supported through some new interfaces.

• Removal of the exported utils object. This was never part of the documented public interface for the package and mainly serves internal npm use cases. The functions attached to this object will be moved to a separate package.

• Drop support for node 14 (required for inclusion in npm v10)

• Update make-fetch-happen to v12 (required for inclusion in npm v10)

Hello sigstore-js devs!

Description

This is a tracking issue for conformance testing between this client implementation and other Sigstore clients, similar to sigstore/sigstore-java#236 and sigstore/sigstore-python#297.

The rough idea here:

• Implement a small "driver" for this Sigstore client, one that adheres to the CLI protocol for the conformance suite
• Add a new conformance.yml workflow that applies the trailofbits/sigstore-conformance action via the driver

@tetsuo-cpp and I are happy to take a stab at the work here, whenever you feel it's appropriate!

cc @di

Description

I was following the steps in the README.md but when I try to sign I just get:

[midawson@midawson sigstore-js]$ ./bin/sigstore.js sign ./node-addon-api-4.3.0.tgz >signature
Error: No identity token provided
    at Signer.getIdentityToken (/home/midawson/sigstore/sigstore-js/dist/sign.js:59:15)
    at async Signer.sign (/home/midawson/sigstore/sigstore-js/dist/sign.js:21:31)
    at async sign (/home/midawson/sigstore/sigstore-js/dist/cli/index.js:48:23)
    at async cli (/home/midawson/sigstore/sigstore-js/dist/cli/index.js:27:13)
    at async Object.processArgv (/home/midawson/sigstore/sigstore-js/dist/cli/index.js:79:9)

I'm running on RHEL 8. Is there some additional configurationt that I need to get the brower window to pop up ?

Version

built from main on Aug 3 2022