@dk/hipp 0.1.33 → 0.1.35
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/README.md +51 -35
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -6,6 +6,16 @@ By Dmytri Kleiner <dev@dmytri.to>
|
|
|
6
6
|
commits and merge conflicts by treating Git Tags as the single source of truth.
|
|
7
7
|
Your `package.json` version stays at `0.0.0` (or matches your latest tag).
|
|
8
8
|
|
|
9
|
+
## TL;DR
|
|
10
|
+
|
|
11
|
+
```bash
|
|
12
|
+
git tag v1.0.0
|
|
13
|
+
git push origin main --tags
|
|
14
|
+
npx @dk/hipp
|
|
15
|
+
```
|
|
16
|
+
|
|
17
|
+
Your package is published with version `1.0.0`. No version-bump commits. No merge conflicts.
|
|
18
|
+
|
|
9
19
|
---
|
|
10
20
|
|
|
11
21
|
## The Problem
|
|
@@ -13,11 +23,11 @@ Your `package.json` version stays at `0.0.0` (or matches your latest tag).
|
|
|
13
23
|
Traditional NPM versioning requires storing the "Version of Truth" in `package.json`.
|
|
14
24
|
This creates a **State Conflict**:
|
|
15
25
|
|
|
16
|
-
- `npm version` and `git tag` are two distinct, non-atomic actions
|
|
17
|
-
- If you tag a commit but forget to update the JSON (or vice-versa), your
|
|
26
|
+
- 🔄 `npm version` and `git tag` are two distinct, non-atomic actions
|
|
27
|
+
- 🤷 If you tag a commit but forget to update the JSON (or vice-versa), your
|
|
18
28
|
registry package and Git history diverge
|
|
19
|
-
- Every release requires a "chore: bump version" commit
|
|
20
|
-
- When multiple branches are developed simultaneously, these trivial changes
|
|
29
|
+
- 🗑️ Every release requires a "chore: bump version" commit
|
|
30
|
+
- 😫 When multiple branches are developed simultaneously, these trivial changes
|
|
21
31
|
cause constant merge conflicts
|
|
22
32
|
|
|
23
33
|
## The Solution
|
|
@@ -25,7 +35,8 @@ This creates a **State Conflict**:
|
|
|
25
35
|
**HIPP makes Git tags the source of truth** - the version is always extracted
|
|
26
36
|
from the tag, not `package.json`. You can leave `package.json` at `0.0.0` (HIPP
|
|
27
37
|
rewrites it during publish) or keep it in sync with your tag (HIPP verifies the
|
|
28
|
-
match).
|
|
38
|
+
match). The published package always has the correct semver from your git tag —
|
|
39
|
+
downstream consumers see normal versions and `npm install` works as expected.
|
|
29
40
|
|
|
30
41
|
---
|
|
31
42
|
|
|
@@ -69,15 +80,15 @@ Pass npm options via `--`:
|
|
|
69
80
|
npx @dk/hipp -- --access public --tag beta
|
|
70
81
|
```
|
|
71
82
|
|
|
72
|
-
HIPP
|
|
83
|
+
### What Happens When You Run HIPP
|
|
73
84
|
|
|
74
|
-
1. **Key Generation
|
|
75
|
-
2. **Verify
|
|
76
|
-
3. **Clean Check
|
|
77
|
-
4. **Validate
|
|
78
|
-
5. **Sign
|
|
79
|
-
6. **Publish
|
|
80
|
-
7. **Confirm
|
|
85
|
+
1. **Key Generation** - Generate Ed25519 signing keys if needed (`hipp.priv`, `hipp.pub`)
|
|
86
|
+
2. **Verify** - Ensure `package.json` version is `0.0.0` or matches the git tag
|
|
87
|
+
3. **Clean Check** - Ensure your git status is clean
|
|
88
|
+
4. **Validate** - Extract and verify the latest tag against Semver rules
|
|
89
|
+
5. **Sign** - Create a cryptographic manifest of your package content
|
|
90
|
+
6. **Publish** - Publish to npm from a staging directory (never mutating your source)
|
|
91
|
+
7. **Confirm** - Ask for confirmation before ignition (skip with `-y`)
|
|
81
92
|
|
|
82
93
|
### Signing Keys
|
|
83
94
|
|
|
@@ -89,15 +100,19 @@ On first run, HIPP generates an Ed25519 keypair:
|
|
|
89
100
|
|
|
90
101
|
The private key holder can sign packages. The public key verifies signatures.
|
|
91
102
|
|
|
92
|
-
|
|
103
|
+
#### Key Rotation
|
|
104
|
+
|
|
105
|
+
Delete `hipp.pub` and run HIPP again. A new keypair will be
|
|
93
106
|
generated and committed automatically. Verification uses the public key from
|
|
94
107
|
the specific git revision at the tag, so previous packages remain verifiable
|
|
95
108
|
with their original keys.
|
|
96
109
|
|
|
97
|
-
|
|
98
|
-
`hipp.pub`, run HIPP, and a new keypair will be generated for that revision.
|
|
110
|
+
#### Multiple Publishers
|
|
99
111
|
|
|
100
|
-
|
|
112
|
+
Each developer can use their own private key. Delete `hipp.pub`, run HIPP, and
|
|
113
|
+
a new keypair will be generated for that revision.
|
|
114
|
+
|
|
115
|
+
#### Why This Works
|
|
101
116
|
|
|
102
117
|
The public key in `hipp.pub` is committed to git at the specific revision of
|
|
103
118
|
each release. Verification always uses the key from that historical revision,
|
|
@@ -110,7 +125,7 @@ not a current one. This means:
|
|
|
110
125
|
|
|
111
126
|
### Options
|
|
112
127
|
|
|
113
|
-
|
|
128
|
+
- `-y, --yes` - Skip the confirmation prompt (ideal for CI/CD pipelines)
|
|
114
129
|
|
|
115
130
|
To pass additional flags to npm publish (like access or a custom registry), use `--`:
|
|
116
131
|
|
|
@@ -133,12 +148,13 @@ npx @dk/hipp verify @scope/package@1.0.0 # verifies specific version
|
|
|
133
148
|
|
|
134
149
|
### How Verification Works
|
|
135
150
|
|
|
136
|
-
|
|
151
|
+
#### Step 1: Get Manifest from npm
|
|
137
152
|
|
|
138
153
|
1. Fetch the package tarball from npm registry
|
|
139
154
|
2. Extract the README and parse the JSON manifest appended to it
|
|
140
155
|
|
|
141
156
|
The manifest contains:
|
|
157
|
+
|
|
142
158
|
```json
|
|
143
159
|
{
|
|
144
160
|
"origin": "git@github.com:dk/your-package.git",
|
|
@@ -155,7 +171,7 @@ The manifest contains:
|
|
|
155
171
|
}
|
|
156
172
|
```
|
|
157
173
|
|
|
158
|
-
|
|
174
|
+
#### Step 2: Clone Git and Verify
|
|
159
175
|
|
|
160
176
|
3. Clone the repository at the tagged commit (using origin/tag from manifest)
|
|
161
177
|
4. Verify the cloned commit hash matches the `revision` field in manifest
|
|
@@ -164,13 +180,13 @@ The manifest contains:
|
|
|
164
180
|
7. Compute SHA256 hash of the clean tarball
|
|
165
181
|
8. Compare with the `hash` field from the npm manifest
|
|
166
182
|
|
|
167
|
-
|
|
183
|
+
#### Step 3: Verify Signature
|
|
168
184
|
|
|
169
185
|
9. Read `hipp.pub` from the cloned repository
|
|
170
186
|
10. Verify the signature was created by signing:
|
|
171
187
|
`hash + "\n" + origin + "\n" + tag + "\n" + revision + "\n" + name + "\n" + email`
|
|
172
188
|
|
|
173
|
-
|
|
189
|
+
#### Step 4: Rebuild Verification
|
|
174
190
|
|
|
175
191
|
11. Append the manifest to the staged README
|
|
176
192
|
12. Update the staged `package.json` version to match the tag
|
|
@@ -186,15 +202,15 @@ The manifest contains:
|
|
|
186
202
|
|
|
187
203
|
### What Verification Guarantees
|
|
188
204
|
|
|
189
|
-
- **Integrity
|
|
190
|
-
- **Authenticity
|
|
191
|
-
- **Reproducibility
|
|
205
|
+
- **Integrity** - The code in npm exactly matches git at the tagged commit
|
|
206
|
+
- **Authenticity** - The package was published by the holder of the private key
|
|
207
|
+
- **Reproducibility** - The npm tarball is byte-for-byte identical to a git rebuild
|
|
192
208
|
|
|
193
209
|
### What Verification Does NOT Guarantee
|
|
194
210
|
|
|
195
|
-
- **Code is safe or bug-free
|
|
196
|
-
- **Publisher is trustworthy
|
|
197
|
-
- **Name/email is accurate
|
|
211
|
+
- **Code is safe or bug-free** - Malicious or buggy code can be signed
|
|
212
|
+
- **Publisher is trustworthy** - The key holder could sign bad code intentionally
|
|
213
|
+
- **Name/email is accurate** - These are read from local `git config` and could be set to anything
|
|
198
214
|
|
|
199
215
|
Verification proves that npm matches git - it says nothing about whether that
|
|
200
216
|
code is correct or safe.
|
|
@@ -239,7 +255,7 @@ HIPP enforces strict integrity rules when publishing:
|
|
|
239
255
|
|
|
240
256
|
## License
|
|
241
257
|
|
|
242
|
-
**0BSD** (BSD Zero Clause License)
|
|
258
|
+
**0BSD** (BSD Zero Clause License) By Dmytri Kleiner <dev@dmytri.to>
|
|
243
259
|
|
|
244
260
|
Permission to use, copy, modify, and/or distribute this software for any
|
|
245
261
|
purpose with or without fee is hereby granted.
|
|
@@ -257,21 +273,21 @@ PERFORMANCE OF THIS SOFTWARE.
|
|
|
257
273
|
Verify this package with [@dk/hipp](https://www.npmjs.com/package/@dk/hipp):
|
|
258
274
|
|
|
259
275
|
```bash
|
|
260
|
-
npx @dk/hipp verify @dk/hipp@0.1.
|
|
276
|
+
npx @dk/hipp verify @dk/hipp@0.1.35
|
|
261
277
|
```
|
|
262
278
|
|
|
263
279
|
```json
|
|
264
280
|
{
|
|
265
281
|
"origin": "git@github.com:dmytri/hipp.git",
|
|
266
|
-
"tag": "v0.1.
|
|
267
|
-
"revision": "
|
|
268
|
-
"hash": "
|
|
269
|
-
"signature": "
|
|
282
|
+
"tag": "v0.1.35",
|
|
283
|
+
"revision": "1867eb114a7c672dd23da33d6b6b4375077faf4d",
|
|
284
|
+
"hash": "8a48b6de8cdfd06b93177720f9701b77dc96263b20c10902a8b5780f5941489a",
|
|
285
|
+
"signature": "R5wbqWXbsV4269e78lDuN92FyWkWk0L4jSsQgLQSVc1/vOis/IKWA+UFMxdIKOfThczLLNm98YDpcu4QEITNBA==",
|
|
270
286
|
"name": "Dmytri Kleiner",
|
|
271
287
|
"email": "dev@dmytri.to",
|
|
272
288
|
"npm": "11.12.1",
|
|
273
289
|
"node": "v25.8.2",
|
|
274
290
|
"git": "git version 2.47.3",
|
|
275
|
-
"hipp": "0.1.
|
|
291
|
+
"hipp": "0.1.35"
|
|
276
292
|
}
|
|
277
293
|
```
|