@forwardreach/saas-ui 0.10.3 → 0.10.4
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/CHANGELOG.md +31 -3
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -1,14 +1,15 @@
|
|
|
1
1
|
# Changelog
|
|
2
2
|
|
|
3
|
-
## 0.10.
|
|
3
|
+
## 0.10.4
|
|
4
4
|
|
|
5
5
|
### Patch Changes
|
|
6
6
|
|
|
7
7
|
- First release published with an npm provenance attestation. The package contents
|
|
8
8
|
are unchanged from `0.10.2`; what is new is that the registry now records where
|
|
9
9
|
this artifact came from — this repository, the commit it was built from, and the
|
|
10
|
-
workflow run that built it — signed by the CI identity and
|
|
11
|
-
consumer can check a version's origin rather than trust
|
|
10
|
+
workflow run that built it — signed by the CI identity and recorded in a public
|
|
11
|
+
transparency log, so a consumer can check a version's origin rather than trust
|
|
12
|
+
its number.
|
|
12
13
|
|
|
13
14
|
That check is what was missing when two vendored tarballs, `@forwardreach/saas-ui@0.9.1`
|
|
14
15
|
and `@forwardreach/saas-mcp@0.1.3`, turned out to carry versions no commit in this
|
|
@@ -16,11 +17,38 @@
|
|
|
16
17
|
version number than the real thing. Nothing in the pipeline could have caught
|
|
17
18
|
either, because a locally packed tarball records no origin at all.
|
|
18
19
|
|
|
20
|
+
`0.10.3` was meant to be this release and shipped without an attestation; see its
|
|
21
|
+
entry for why. Both numbers stay retired rather than reissued.
|
|
22
|
+
|
|
19
23
|
Verify an installed copy with `npm audit signatures`, or from a clone of this
|
|
20
24
|
repository with `node scripts/verify-provenance.mjs @forwardreach/saas-ui@<version>`.
|
|
21
25
|
Neither needs registry credentials. Versions published before this one cannot
|
|
22
26
|
gain an attestation retroactively.
|
|
23
27
|
|
|
28
|
+
## 0.10.3
|
|
29
|
+
|
|
30
|
+
### Patch Changes
|
|
31
|
+
|
|
32
|
+
- **No provenance attestation, despite what this release was for.** `0.10.3` was
|
|
33
|
+
published to be the first artifact carrying one, and it is not: the package
|
|
34
|
+
contents are identical to `0.10.2` and the registry reports no
|
|
35
|
+
`dist.attestations` for it. Use `0.10.4` or later if you want a version whose
|
|
36
|
+
origin you can check; this number is spent and will not be reissued.
|
|
37
|
+
|
|
38
|
+
The cause is worth recording, because it is exactly the silent failure the
|
|
39
|
+
verification step was added to catch. `changeset publish` detects a pnpm
|
|
40
|
+
workspace and shells out to `pnpm publish`, and pnpm does not read arbitrary
|
|
41
|
+
`NPM_CONFIG_*` environment variables into its configuration — it reads
|
|
42
|
+
`provenance` as an rc option only. So `NPM_CONFIG_PROVENANCE=true` was
|
|
43
|
+
accepted by the shell, ignored by the publisher, and the package went out
|
|
44
|
+
with no attestation and no warning of any kind. Nothing in the publish output
|
|
45
|
+
suggested anything was wrong. `pnpm config get provenance` even reports
|
|
46
|
+
`true` for that env var, so it is not a usable pre-flight check either.
|
|
47
|
+
|
|
48
|
+
The release failed red rather than reporting success, which is the property
|
|
49
|
+
that mattered: the post-publish check queried the registry, found no
|
|
50
|
+
attestation, and stopped the run before tags were pushed.
|
|
51
|
+
|
|
24
52
|
## 0.10.2
|
|
25
53
|
|
|
26
54
|
### Patch Changes
|
package/package.json
CHANGED