mirror of
https://github.com/johannesjo/super-productivity.git
synced 2026-07-17 16:37:43 +00:00
462fb616c9
File-based providers (WebDAV, Dropbox, OneDrive, Nextcloud, LocalFile) derived "should I encrypt?" from key presence alone, so a silently dropped credential-store key made the next sync upload the full sync-data.json in plaintext with no error — same class as GHSA-9v8x, which only covered SuperSync. Root cause: there was no durable, per-provider record of encryption intent. The global sync.isEncryptionEnabled flag is shared across providers and re-derived from key presence in the settings form, so it is unreliable in both directions (stale-true after a SuperSync→file switch; flipped false by a routine save once the key is gone). Fix — persist intent per provider, enforce at one boundary, recover uniformly: - Store isEncryptionEnabled in each file-based provider's privateCfg, written atomically with the key on enable/disable (closes the non-atomic disable window) and backfilled from the key present at save time / first sync for pre-fix configs. Read everywhere as `isEncryptionEnabled ?? !!encryptKey`. - WrappedProviderService now derives the adapter's isEncrypt from this per-provider intent, not the global flag — so a stale global flag no longer blocks legitimate plaintext sync and privateCfg writes keep the adapter cache correct. - The upload service fails closed for file-based intent-on-but-key-gone via a new adapter hook (isEncryptionKeyMissing), throwing EncryptNoPasswordError BEFORE either upload loop — never plaintext, and never the permanent markRejected the snapshot path would apply. - SyncWrapperService routes EncryptNoPasswordError to the enter-password recovery dialog on the main sync, force-upload and USE_LOCAL conflict paths (previously only main sync; the others dead-ended in a snack). - The encrypt handler keeps throwing on isEncrypt-without-key as a last-line backstop. Residual: a pre-fix config whose key is dropped before intent is ever recorded (never synced/saved after upgrade) cannot be distinguished from "never encrypted" and is not retroactively protected — no record exists. Regression tests per layer: adapter hooks, upload-boundary guard, per-provider intent persistence, form derivation/preservation, and conflict-path recovery routing. |
||
|---|---|---|
| .. | ||
| plugin-api | ||
| plugin-dev | ||
| shared-schema | ||
| super-sync-server | ||
| sync-core | ||
| sync-providers | ||
| vite-plugin | ||
| build-packages.js | ||
| README.md | ||
Super Productivity Packages
This directory contains plugin packages and the plugin API for Super Productivity.
Structure
plugin-api/- TypeScript definitions for the plugin APIplugin-dev/- Plugin development examples and toolsapi-test-plugin/- Basic API test pluginprocrastination-buster/- Example SolidJS-based pluginyesterday-tasks-plugin/- Simple plugin showing yesterday's tasksboilerplate-solid-js/- Template for creating new SolidJS plugins (not built)sync-md/- Markdown sync plugin (not built)
Building Packages
All packages are built automatically when running the main build process:
npm run build:packages
This command:
- Builds the plugin-api TypeScript definitions
- Builds plugins that require compilation (e.g., procrastination-buster)
- Copies plugin files to
src/assets/for inclusion in the app
Development
To work on a specific plugin:
cd plugin-dev/[plugin-name]
npm install
npm run dev
Adding a New Plugin
- Create a new directory in
plugin-dev/ - Add the plugin configuration to
/packages/build-packages.js - Run
npm run build:packagesto test the build
Notes
- The
boilerplate-solid-jsandsync-mdplugins are development templates and are not included in production builds - Plugin files are automatically copied to
src/assets/during the build process - The build script handles dependency installation automatically