* fix(sync): authenticate the project-move footprint on encrypted LWW ops
SuperSync E2EE (AES-256-GCM) covers only `op.payload`; `op.entityId`/`entityIds`
travel as plaintext beside the ciphertext. The LWW project-repair reducer trusts
`meta.entityIds` (copied verbatim from that envelope) to move EVERY declared task
out of its project, so a compromised sync server could append victim task ids to
the envelope of an otherwise-valid encrypted move and orphan those tasks — without
touching the authenticated payload.
Bind the envelope footprint to the authenticated one: on the decrypt path, require
exact-set equality between `op.entityIds` and `{op.entityId} ∪
payload.projectMoveSubTaskIds`.
Interim hardening: enforced only when the authenticated payload carries a
`projectMoveSubTaskIds` array. Synthetic conflict-resolution LWW ops legitimately
carry `entityIds` with no such payload field (footprint lives only in the
envelope), so they are left untouched to avoid rejecting valid ops. Fully closing
the envelope-injection vector needs the durable fix (bind the footprint as GCM
AAD behind an envelope-versioned migration), which remains open. GHSA-8pxh-mgc7-gp3g.
* fix(sync): two data-loss fixes on the snapshot-hydration path
Both bugs surface when a remote snapshot replaces live state, and both live in
sync-hydration.service.ts — kept together as one change.
(1) Atomic rejection of superseded local ops. The file-based bootstrap rejected
pending local ops via a standalone markRejected() that commits in its own
transaction BEFORE commitFileSnapshotBaseline(). If that baseline commit then
threw (e.g. the op-log tail changed), the old state survived but the ops were
already durably rejected — permanently non-uploadable local edits. Fold the
rejection into the baseline transaction via a new `rejectOpIds` param so it is
atomic with the state replacement, and notify the user only after it commits.
(2) Flush the tracked-time accumulator before replacing NgRx. Time tracking
buffers a delta in memory for up to five minutes; a hydration in that window
replaced live state without flushing it, so the later flush dispatched a LOCAL
syncTimeSpent the reducer ignores — silently dropping the tracked time. Flush the
accumulator into a durable op before loadAllData (mirroring how clean-slate and
backup handle their own replacement paths), placed after the baseline commit so
the appended op can't move the tail past the asserted seq.
* test(sync): cover the #3 tracked-time flush-across-hydration path
Adds a deterministic scenario to the task-time replay state machine: a delta
tracked but not yet flushed, flush()ed before a snapshot replaces the store,
becomes a durable syncTimeSpent op that re-applies additively on replay onto the
delta-less remote baseline (and, without the flush, the baseline stays
under-counted). Together with the sync-hydration unit test (flush runs before
loadAllData) this covers the flush → durable-op → replay chain the #3 fix relies
on.
* fix(sync): fail-safe the conflict-journal clear on profile switch (privacy)
ConflictJournalService.clearAll() swallows IndexedDB clear() failures — by
contract, it must not throw after the dataset was already replaced during a
profile switch. But if the bulk clear failed, the next profile could still see
the previous dataset's task titles / field values in the conflict-review UI: a
cross-profile privacy leak.
Persist a durable "cleared before" timestamp in localStorage (which does not
depend on the journal's own IndexedDB being healthy) before the bulk clear. The
read paths — list(), getEntry(), and the badge count — hide every entry resolved
at or before that boundary, so a swallowed clear failure can never surface stale
content. The marker is dropped on a successful clear, and pruneOnStart physically
reclaims any hidden survivors and drops the marker on the next app start.
The boundary favors hiding (entries resolved at the exact clear instant are
treated as pre-clear), matching the privacy-fail-safe intent. Known edge-case
limitations (timestamp vs monotonic clock, localStorage durability, a future
localStorage.clear()) are documented on the marker constant.
Held from public issue tracking (privacy). 4 tests added; 31/31 green.
Hardened per a 3-agent review (correctness / privacy-completeness / lean).
* test(sync): round-trip the encrypted project-move footprint through real crypto (#2)
Exercises the #2 integrity gate through the actual encrypt→decrypt flow (real
AES-GCM), not just the isolated integrity function: a legitimate move round-trips
(entityIds ride OUTSIDE the ciphertext — no false positive), a server-tampered
entityIds footprint is rejected on both the single and batch decrypt paths, and a
synthetic envelope-only op (no authenticated projectMoveSubTaskIds) is accepted.
Closes the one gap flagged in the confidence review: proves the attack model and
the fail-closed behaviour in the real pipeline.
|
||
|---|---|---|
| .agents/skills/commit-messages | ||
| .air | ||
| .codex | ||
| .devcontainer | ||
| .github | ||
| .husky | ||
| .signpath/policies/super-productivity | ||
| .vscode | ||
| android | ||
| build | ||
| docs | ||
| e2e | ||
| electron | ||
| eslint-local-rules | ||
| fastlane | ||
| ios | ||
| nginx | ||
| packages | ||
| scripts | ||
| snap/hooks | ||
| src | ||
| tools | ||
| .browserslistrc | ||
| .dockerignore | ||
| .editorconfig | ||
| .env.example | ||
| .gitattributes | ||
| .gitignore | ||
| .gitmodules | ||
| .gitpod.yml | ||
| .npmrc | ||
| .nvmrc | ||
| .prettierignore | ||
| .prettierrc.json | ||
| .stylelintrc.mjs | ||
| AGENTS.md | ||
| angular.json | ||
| ARCHITECTURE-DECISIONS.md | ||
| capacitor.config.ts | ||
| CLAUDE.md | ||
| CONTRIBUTING.md | ||
| docker-compose.e2e.fast.yaml | ||
| docker-compose.e2e.yaml | ||
| docker-compose.supersync.yaml | ||
| docker-compose.yaml | ||
| docker-entrypoint.sh | ||
| Dockerfile | ||
| Dockerfile.e2e.dev | ||
| Dockerfile.e2e.dev.fast | ||
| electron-builder.yaml | ||
| eslint.config.js | ||
| funding.json | ||
| Gemfile | ||
| Gemfile.lock | ||
| LICENSE | ||
| ngsw-config.json | ||
| package-lock.json | ||
| package.json | ||
| README.md | ||
| SECURITY.md | ||
| tsconfig.base.json | ||
| tsconfig.json | ||
| webdav.yaml | ||
An advanced todo list app with timeboxing & time tracking capabilities that supports importing tasks from your calendar, Jira, GitHub and others
🌐 Open Web App or 💻 Download
💻 Downloads & Install
For all current downloads, package links, and platform-specific notes:
check the wiki
✔️ Features
- Keep organized and focused! Plan and categorize your tasks using sub-tasks, projects and tags and color code them as needed.
- Use timeboxing and track your time. Create time sheets and work summaries in a breeze to easily export them to your company's time tracking system.
- Helps you to establish healthy & productive habits:
- A break reminder reminds you when it's time to step away.
- The anti-procrastination feature helps you gain perspective when you really need to.
- Need some extra focus? A Pomodoro timer is also always at hand.
- Collect personal metrics to see, which of your work routines need adjustments.
- Integrate with Jira, Trello, GitHub, GitLab, Gitea, OpenProject, Linear, ClickUp and Azure DevOps. Auto import tasks assigned to you, plan the details locally, automatically create work logs, and get notified immediately, when something changes.
- Basic CalDAV integration.
- Back up and synchronize your data across multiple devices with Dropbox and WebDAV support
- Attach context information to tasks and projects. Create notes, attach files or create project-level bookmarks for links, files, and even commands.
- Super Productivity respects your privacy and does NOT collect any data and there are no user accounts or registration. You decide where you store your data!
- It's free and open source and always will be.
And much more!
Note
The web version has some limitations: See the Web App vs Desktop comparison for more details.
📖 Documentation and Guides
Getting Started
- Getting started guide (article)
- Video walkthrough (YouTube)
- Eat the frog prioritizing scheme
Starting Point in Wiki:
First steps •
Reference •
How-To
Productivity Tips:
Keyboard Shortcuts •
Short Syntax
Need Help?
Visit the discussions page
See the bottom of the README for more information on the documentation.
Advanced Topics
Here are some other topics covered in the official wiki:
Development:
Run dev server •
Package the app •
Build for Android •
Run with Docker
Data Management:
User Data •
Issue Providers •
Sync Providers
Customization:
Plugins •
Themes
APIs:
Sync Server •
Plugins •
REST
Community
The development of Super Productivity is driven by a wonderful community of users and contributors. Thank you all so much for your support!
👀 Check out our awesome curated list of community-created resources about Super Productivity
♥️ Contributing
If you want to get involved, please check out the CONTRIBUTING.md
There are several ways to help.
-
Spread the word: More users mean more people testing and contributing to the app which in turn means better stability and possibly more and better features. You can vote for Super Productivity on Slant, Product Hunt, Softpedia or on AlternativeTo, you can tweet about it, share it on LinkedIn, reddit or any of your favorite social media platforms. Every little bit helps!
-
Provide a Pull Request: Here is a list of the most popular community requests and here some info on how to run the development build (wiki). Please make sure that you're following the commit message format and to also include the issue number in your commit message, if you're fixing a particular issue (e.g.:
feat: add nice feature #31). -
Answer questions: You know the answer to another user's problem? Share your knowledge!
-
Provide your opinion: Some community suggestions are controversial. Your input might be helpful and if it is just an up- or down-vote.
-
Provide a more refined UI spec for existing feature requests
-
Make a feature or improvement request: Something can be done better? Something essential missing? Let us know!
-
Translations, Icons, etc.: You don't have to be a programmer to help; learn how to contribute translations!
-
Create custom plugins or custom themes
Special Thanks to our Sponsors!!!
Recently support for Super Productivity has been growing! A big thank you to all our sponsors!
(If you are, intend to or have been a sponsor and want to be shown here, please let me know!)
Code Signing
Windows binaries are signed. Free code signing is provided by SignPath.io, certificate by SignPath Foundation.
Documentation: Manual versus Automated
There are two wikis: the official one hosted in by GitHub and the autonomously generated variant using DeepWiki.com. The manually curated version is a more stable and approachable resource designed to help you understand the app from a more human-focused perspective whereas DeepWiki is optimized for explaining the code itself with little regard for context beyond that.
Official Wiki
It is preferable to maintain local documentation rather than rely on an external service. It also preferable that the documentation is updated in tandem with the code changes as demonstrated in this commit.
Changes to files within ./docs/wiki are linted in CI before being automatically
sync'd to the repository's official Wiki hosted by GitHub.
Migrating to Docusaurus is a long-term goal once the content and structure of the wiki has matured and the remaining "legacy docs" have either been reworked or removed. There are some automations in development to help reduce the difference between the published docs and the state of the code while retaining a human-in-the-loop.
DeepWiki.com
If you have very specific questions about how the code works or why a bug might be producing
a particular message it might be useful to
. It can help "cite your sources" when discussing functionality and code that you don't fully
understand as part of feature requests or bug reports.
This automated reference does come with some significant drawbacks:
- Intent: Describes what code does, not why decisions or tradeoffs were made.
- Staleness: Will *always* lag behind the code.
- Code-Focused: Does not provide guides or conceptual explanations.
- Cost: Potential future cost and higher resource usage than static docs.

