Scrib Desktop 1.10.0. Saves That Keep Every Keystroke

Scrib Desktop is the Windows companion to the Scrib encrypted notes app: a tabbed text editor that encrypts files with AES-256, handles plain text and rich text, and works fully offline with no account and no tracking. The last release post covered 1.7.0 and its locked tabs.

This release adds nothing. It exists because a full review of the code found two ways the editor could lose your work without telling you.

Both bugs had been there since the first release. Neither ever showed an error. That is the part worth writing about, because it generalizes past this app: the dangerous failures in a text editor are not the crashes. They are the saves that report success.

Scrib Desktop. A multi-tab encrypted editor for Windows, free and open source under GPL-3.0.

The first bug: text typed during a save was thrown away

Scrib saves in the background. Auto-save runs every 30 seconds, and there are save paths on close and on quit. A save is not instant, and an encrypted save is considerably slower than a plain one: it derives a key with PBKDF2-SHA256 at 100,000 iterations, encrypts, computes an HMAC, and writes the file atomically. Well over a tenth of a second, every time.

Here is what went wrong in that window. When the write finished, Scrib marked the tab clean by comparing it against the tab's current content, not against the bytes it had actually just written. So anything you typed during the write was recorded as already saved. The dirty marker cleared. The close prompt saw nothing pending. Quit, and the sentence was gone, with the editor having reported a successful save the whole time.

The fix is a snapshot. A save now captures exactly the content it is about to write, and when the write completes it marks the tab clean against that, not against whatever is on screen a quarter of a second later. Text typed during the write no longer matches, so the tab stays unsaved and the next save picks it up. The regression test for this types into the tab from inside the file-write call, which is the only way to reproduce it reliably.

The second bug: encrypting a file could destroy a different one

Ctrl+E does not only encrypt. It changes the file's extension: notes.txt becomes notes.scrb. The plain and rich text toggle does the same thing between .txt and .rtf.

Before 1.10.0, that new path was written with no questions asked. If a notes.scrb already existed at the destination, from an earlier encrypted note, a backup, anything at all, it was replaced. Then the .txt source was deleted. Two files in, one file out, no prompt, no backup, no undo.

Now any save that changes a file's extension asks before replacing an existing file. And if that prompt cannot be shown, which is the case for a background save, the save declines rather than guessing. That is the general rule this release settled on: a refused save leaves the tab unsaved and says so. An editor that reports success for a write it did not perform is worse than one that fails loudly.

Two smaller versions of the same problem went with it. Save As now refuses a file another tab already has open, which previously left the two tabs overwriting each other. And naming an untitled tab asks before replacing an existing file.

Files another program changed are no longer overwritten

Leave a note open in Scrib. Edit the same file in another program, or let a sync client pull down a newer copy from another machine. Before 1.10.0, the next auto-save replaced it, silently.

Scrib now records a file's modification time and size when it reads or writes it, and checks them before writing again. If the file changed underneath, a background save refuses and leaves the tab unsaved; a manual save asks first. This matters most if your notes live in OneDrive, Dropbox, Syncthing, or any folder something else writes to.

How do I know if my own editor has this problem?

You can check any editor in about thirty seconds, and it is worth doing on whatever you actually write in:

1. Open a text file in your editor and leave it open.
2. Open the same file in Notepad, add a line, save, and close Notepad.
3. Back in your editor, type one character and save.
4. Open the file in Notepad again.

If the line you added in Notepad is gone and nothing warned you, your editor overwrote an external change without asking. Editors that handle this show a "file has changed on disk" prompt at step 3. Scrib Desktop did not, until this release. Neither does Windows Notepad itself.

The plaintext an encrypt used to leave behind

Press Ctrl+E on notes.txt and Scrib writes notes.scrb, then removes the original. It has removed the original since 1.4.0, which is what most people assume "encrypt this file" means.

But deleting a file on Windows only unlinks it. The bytes stay on the disk until something else claims that space, and ordinary undelete tools read them back. So a note you encrypted last month could still be sitting there in plaintext. 1.10.0 overwrites the original's bytes before removing it, and does the same to any stray backup file an interrupted save left behind.

The honest limit, which is also in the README threat model: overwriting is best effort by nature. On an SSD, the controller may write your overwrite to a fresh block and leave the original one intact until it gets around to erasing it. A backup, a filesystem snapshot, or a synced folder can hold a copy Scrib never sees. If a note must never exist in plaintext, create it encrypted rather than converting one.

The rest of the security work

• Locking a tab clears more. Ctrl+L now also clears the tab's undo history, the decoded images held in memory, and the clipboard when it holds text copied from that note. The undo stack used to keep the decrypted text after the lock screen went up.
• A note cannot be locked over a plaintext file. Marking a .txt as encrypted and then locking it used to show a lock screen over a file that was not encrypted, and that could never be unlocked.
• Change Password fails cleanly. If the re-encrypt failed, the interface said so while the app quietly kept the new password and used it on the next save. The password now commits only after the write succeeds.
• Ctrl+click shows a link's real destination before opening it, and a link Scrib blocks now says so instead of doing nothing.
• The password strength meter got stricter. It now accounts for common passwords, keyboard runs, and repeated characters, so some passwords it used to call Strong rate lower. That is the meter getting more honest, not your password getting weaker.
• Hostile files are bounded. Reads are capped at 64 MB, and crafted .rtf, table, and image payloads can no longer hang the app or exhaust memory. Opening a note someone sent you means parsing untrusted input, and there is no sandbox around that parsing.

Rich text, search, and the rest

• Coloured and highlighted text no longer gains a stray space on every save to RTF, and the colours are now exported instead of dropped.
• Table cell edits are no longer lost when a tab closes mid-edit, and copying a table no longer sends edits to the wrong copy.
• Whole-word search no longer skips matches that follow a rejected candidate, and it now recognises accented and non-Latin words. Replace All used to corrupt them.
• Text files that are not valid UTF-8, the sort of .log and .csv and .ini older Windows tools produce, now open instead of being refused.
• Clearing recent files and turning off session restore now remove the stored note paths from disk. The settings database appends rather than rewrites, so the earlier entries used to stay readable in the file after you cleared them.
• Launching a second copy of Scrib explains that one is already running instead of exiting invisibly.

How these were found, including one the review itself created

1.10.0 came out of two passes over the code: a review split across subsystems, then an adversarial security pass whose only job was to attack the first pass's work.

The second pass paid for itself immediately. The fix for the mid-save bug, the one that records what was written, had introduced a new problem of its own. If a tab was locked while its save was still in flight, the completion step put the decrypted text back into the locked tab and pinned it unsaveable. The older, less correct code had avoided that by accident. It was caught, reproduced as a failing test, and fixed before the release went out.

Every data-loss and security fix above was written the same way: a test that fails against 1.9.0 first, then the fix. The suite grew from 518 tests to 613, 95 of them new in this release. The full list is in the CHANGELOG.

Your files are safe, and there is still no installer

The .scrb file format and your settings are unchanged in 1.10.0. Every existing encrypted file opens with the same password, and a file saved by 1.10.0 opens in 1.3.0 or later. Scrib Desktop ships as a portable zip, not an installer, so nothing touches your registry or system folders. Updating means extracting the new folder over the old one.

Download and verify

1. Download scrib-desktop-v1.10.0-windows-x64.zip (direct link, about 13 MB).
2. Extract it anywhere.
3. Run scrib_desktop.exe.

Windows may warn about an unsigned app. Choose More info, then Run anyway. The build is not code-signed, and that is a real gap rather than an oversight to gloss over.

What is new in 1.10.0 is that each release now publishes a build provenance attestation, so you can tie the zip you downloaded to the public workflow run and commit that produced it:

gh attestation verify scrib-desktop-v1.10.0-windows-x64.zip --repo beeswaxpat/scrib-desktop

That needs the GitHub CLI, and it is a stronger check than the published SHA-256 file. The checksum is generated by the same workflow that builds the zip, so it proves the download was not corrupted in transit and nothing more. Earlier wording on this site and in the README implied more than that; the README now states it plainly. The release page and the full source are on GitHub, and issues and pull requests are welcome.

Questions

Keep Reading

• Scrib Desktop 1.7.0. Lock Encrypted Notes Without Closing Them: locked tabs, idle auto-lock, and session restore that reopens encrypted notes locked.
• Encrypted Notepad for Windows: What Actually Works: Notepad has no password feature, and here is what does.
• 5 Best Private Notes Apps for Windows, Compared: Scrib Desktop against Joplin, Standard Notes, Obsidian, and Notesnook.
• Scrib Desktop Is Now Open Source: how the encryption is built, with the source.
• Notes App Encryption at Rest: What It Protects and What It Does Not: the honest version of what AES-256 buys you.