Skip to content

M13 packaging - #15

Merged
willkotheimer merged 2 commits into
mainfrom
m13-packaging
Sep 4, 2026
Merged

willkotheimer merged 2 commits into
mainfrom
m13-packaging

Conversation

@willkotheimer

Copy link
Copy Markdown
Owner

No description provided.

willkotheimer and others added 2 commits September 3, 2026 18:04
…upgrade

electron-builder produces a per-user NSIS installer and, once the Partner Center
identity values are filled in, an MSIX for the Store. `publish: null` is set on
purpose: left unset, electron-builder writes an `app-update.yml` naming a GitHub
feed, and shipping a file that advertises an updater this app does not have would
undercut the whole claim.

A first-run screen carries the 5f statement, and nothing is captured until it is
acknowledged. The session refuses capture while `firstRun` is true and the answer
is remembered in settings; the default is the cautious one, so a build that loses
its settings collects nothing until asked again.

The upgrade test of invariant 5 was run as written and passed, with the migration
performed by the artifact that ships. An M6 worktree wrote a genuine v1 file with
three clips and a cursor; the NSIS installer was then installed and its app
opened that same file, bringing it to v4 with every clip id, position, content,
the cursor and the file's created_at unchanged, and the new columns added with
defaults. That build then captured into the migrated file, which also proves the
clipboard addon and SQLCipher load from app.asar.unpacked in a real install.

The installer is not signed. Azure Trusted Signing needs an Azure subscription
and a validated identity, so the SmartScreen criterion cannot be met yet; the
configuration is present and commented rather than substituted with something
weaker.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The privacy statement told the user the database key was held in Windows
Credential Manager. It is not. Electron's safeStorage seals through Chromium's
OSCrypt, which keeps a random AES key in the app's own Local State file and
protects that key with DPAPI: the stored value literally begins with the ASCII
bytes `DPAPI` followed by a DPAPI blob header, and the sealed key cannot be
opened from a different user-data directory, which a Credential Manager entry
would not care about. PLAN.md 12 and key.ts said DPAPI all along; only the two
screens the user actually reads said otherwise.

The same sentence overstated a second thing. "Never in a file" is false — the
sealed key is a file, spool.key. What is true is that it is never written in
plaintext, which is what it now says.

`keyStoreName` becomes `keySealerName`, since what is being named is the thing
that seals the key rather than a store that holds it, and a regression test
pins that the Windows answer does not name the Credential Manager.

Found by screenshotting the installed build rather than querying its database.
Every earlier check of the package read main-process state, and the renderer is
exactly where packaging diverges, so a wrong or blank screen would have passed
all of them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@willkotheimer
willkotheimer merged commit 9fe3815 into main Sep 4, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant