RFC for linking packages to their source and build

accepted/0000-link-packages-to-source-and-build.md

@@ -50,7 +50,12 @@ Open source maintainers must be able to link their packages to the source and bu
 ## Non-goals
 - Support for private/inner-source packages to begin with.
   - Our primary goal is to link packages hosted on the npm registry to the source and build it originated from, for this to be broadly useful, the source code and build need to be publicly available. We're committed to eventually supporting private use cases.
-- Support for self-hosted CI/CD systems.
+- Support signing from self-hosted CI/CD systems.
+- Support signing from local machines or laptops.
+  - The initial goal does not support signing from your local laptop as our primary aim is to link the package to the source repo it was published from. There's no scalable way of making sure this source information isn't falsified when it comes from a local machine.
+- Linking already published packages to their source repository to detect if a published package might have untracked changes.
+  - The idea here would be to attempt to rebuild an already published package from the source defined in the `package.json` and create a signed link if the source matches the published package. This would give some of the same benefits as described in this RFC for existing packages without any effort from the maintainer.
+  - Supporting legacy packages isn't planned as part of the initial work but something we remain open to exploring in the future as we see this being built on top of the capabilities we would be adding here. This proposal lays out the building blocks for signing metadata about a package (attestations) that we can build on.
 - Mitigate every possible supply chain attack against the npm registry. For example:
   - Registry/mirror/proxy MITM attacks
   - Denial of service attacks against the registry or client from a compromised mirror/proxy
@@ -435,7 +440,11 @@ Non-falsifiable provenance information is a [requirement to reach SLSA level 3](
 
 Using a trusted builder to publish an npm release will ensure a higher level of build integrity. Using it will be optional, but highly recommended. Verification of build provenance will include checks to determine if a trusted builder was used.
 
-At a high level, the trusted builder will checkout the git repo, install dependencies and execute `npm run build` followed by `npm publish`. Maintainers can only control what is run during `npm run build` not add or remove steps from the trusted builder. Provenance generation will be run in a separate workflow step that's isolated from the build and install.
+At a high level, the trusted builder will checkout the git repo, install dependencies and execute a user supplied build command (e.g. `npm run build`) followed by `npm publish`. 
+
+The primary function of the trusted builder is to know what went into the build (inputs, environment variables etc) and what commands where run. See this [provenance example from the slsa-github-generator for a go project](https://github.com/slsa-framework/slsa-github-generator/tree/main/internal/builders/go#provenance-example).
+
+Maintainers can only control what is run during the build and not add or remove steps from the trusted builder.
 
 Using the trusted builder does not guarantee that your project has reached SLSA level 3. This could be achieved on a case-by-case basis by auditing the build scripts, making sure no untrusted scripts are fetched from outside the source repo and executed.
 
@@ -602,13 +611,6 @@ It's technically possible to use something like this to produce verifiable build
 
 Implementation for verifying [SLSA Provenance](/Users/feelepxyz/src/github.com/npm/rfcs/accepted/0000-link-packages-to-source-and-build.md). It currently supports verifying provenance generated by the [SLSA generator for Go projects](https://github.com/slsa-framework/slsa-github-generator/blob/main/.github/workflows/builder_go_slsa3.yml).
 
-## Unanswered questions
-
-- How could we support legacy packages that might not be maintained anymore?
-  - Would it be possible to backfill "provenance" on packages where code in an existing repository link defined in `package.json` can be matched against the published package?
-  - It seems theoretically possible to backfill provenance if the source can be matched but doing this reliably is not a solved problem and would require fine tuning heuristics to build the package and find the corresponding release, for example inferring typescript compilation and finding the release via tags on the repo.
-  - Supporting legacy packages isn't planned as part of any initial work, it's also not clear if it would be worth the engineering effort.
-
 ## Glossary
 
 Overview of the tools, techniques and terms used throughout this RFC document.