@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.
Files changed (2) hide show
  1. package/README.md +51 -35
  2. 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 will:
83
+ ### What Happens When You Run HIPP
73
84
 
74
- 1. **Key Generation**: Generate Ed25519 signing keys if needed (`hipp.priv`, `hipp.pub`)
75
- 2. **Verify**: Ensure `package.json` version is `0.0.0` or matches the git tag
76
- 3. **Clean Check**: Ensure your git status is clean
77
- 4. **Validate**: Extract and verify the latest tag against Semver rules
78
- 5. **Sign**: Create a cryptographic manifest of your package content
79
- 6. **Publish**: Publish to npm from a staging directory (never mutating your source)
80
- 7. **Confirm**: Ask for confirmation before ignition (skip with `-y`)
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
- **Key rotation**: Delete `hipp.pub` and run HIPP again. A new keypair will be
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
- **Multiple publishers**: Each developer can use their own private key. Delete
98
- `hipp.pub`, run HIPP, and a new keypair will be generated for that revision.
110
+ #### Multiple Publishers
99
111
 
100
- ### Why This Works
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
- * `-y, --yes`: Skip the confirmation prompt (ideal for CI/CD pipelines).
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
- **Step 1: Get manifest from npm**
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
- **Step 2: Clone git and verify**
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
- **Step 3: Verify signature**
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
- **Step 4: Rebuild verification**
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**: The code in npm exactly matches git at the tagged commit
190
- - **Authenticity**: The package was published by the holder of the private key
191
- - **Reproducibility**: The npm tarball is byte-for-byte identical to a git rebuild
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**: Malicious or buggy code can be signed
196
- - **Publisher is trustworthy**: The key holder could sign bad code intentionally
197
- - **Name/email is accurate**: These are read from local `git config` and could be set to anything
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) By Dmytri Kleiner <dev@dmytri.to>
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.33
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.33",
267
- "revision": "9374cd1fb9e8046983abaebd21f4812bcc80ef5a",
268
- "hash": "bb54c711b30be14366f26749253801f8a9ac13efaa774d2aa5f6044f5f9980bb",
269
- "signature": "U7oLJCB+Efv5tWJ9Zy7kp4saa+i1K7Z7N8+vW6e0l0AZahQpTPhZiM1ZMC5MM5g8rxnjt/NxwwCUEacVoDiPCg==",
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.33"
291
+ "hipp": "0.1.35"
276
292
  }
277
293
  ```
package/package.json CHANGED
@@ -1,6 +1,6 @@
1
1
  {
2
2
  "name": "@dk/hipp",
3
- "version": "0.1.33",
3
+ "version": "0.1.35",
4
4
  "description": "High Integrity Package Publisher",
5
5
  "main": "hipp.js",
6
6
  "bin": {