Found reviewing #1021 (sirtimid/crank-rollback-integrity).
What
#1021 removes better-sqlite3's verbose from the nodejs driver, for a stated privacy reason: "it fires on every statement with values inlined, and kernel store rows carry vat state and c-list entries". The same PR then hands the wasm driver a logger for the first time, and there kvSet and kvDelete do:
logger?.debug(`kv set '${key}' to '${value}'`)That is the same disclosure by a different route, in the browser extension.
Why it fires
new Logger('kernel-worker') uses the default console transport, whose default level is debug. So every kernel-store write in the extension emits a console line containing the full value — vat state, c-list entries, capdata — and setupConsoleForwarding in the same file ships console output to the panel.
The kernel-store changelog's own bullet ("Kernel store rows carry vat state, c-list entries and capability data") argues against the browser-runtime changelog's bullet in the same PR.
Suggested fix
Either drop the logger argument where kernel-worker.ts constructs the store — the wasm driver's discardTransaction diagnostics are the stated motive, and a sub-logger scoped to the transaction paths would carry those without reaching makeKVStore — or stop passing the ['kv'] sub-logger into makeKVStore and delete the two logger?.debug value lines.
The nodejs side is fine: its makeKVStore takes no logger.
Related: dropping verbose has no test, so a one-line revert would reintroduce the nodejs half silently.
Found reviewing #1021 (
sirtimid/crank-rollback-integrity).What
#1021 removes better-sqlite3's
verbosefrom the nodejs driver, for a stated privacy reason: "it fires on every statement with values inlined, and kernel store rows carry vat state and c-list entries". The same PR then hands the wasm driver a logger for the first time, and therekvSetandkvDeletedo:That is the same disclosure by a different route, in the browser extension.
Why it fires
new Logger('kernel-worker')uses the default console transport, whose default level isdebug. So every kernel-store write in the extension emits a console line containing the full value — vat state, c-list entries, capdata — andsetupConsoleForwardingin the same file ships console output to the panel.The kernel-store changelog's own bullet ("Kernel store rows carry vat state, c-list entries and capability data") argues against the browser-runtime changelog's bullet in the same PR.
Suggested fix
Either drop the
loggerargument wherekernel-worker.tsconstructs the store — the wasm driver'sdiscardTransactiondiagnostics are the stated motive, and a sub-logger scoped to the transaction paths would carry those without reachingmakeKVStore— or stop passing the['kv']sub-logger intomakeKVStoreand delete the twologger?.debugvalue lines.The nodejs side is fine: its
makeKVStoretakes no logger.Related: dropping
verbosehas no test, so a one-line revert would reintroduce the nodejs half silently.