fix(worker): store iv as hex string instead of raw bytes#76
Merged
Androz2091 merged 1 commit intomainfrom May 1, 2026
Merged
Conversation
The SavedPackageData.iv column is String(255), but the worker was writing the raw bytes returned by os.urandom(16). SQLAlchemy/psycopg2 serialize bytes-into-text as PostgreSQL's BYTEA literal "\x..." + hex, which then flowed straight to the client through /blob's JSON response. The frontend tried to use that as a hex IV, AES-CBC produced garbage, and the loading screen was stuck on "processing" forever. Fix: write iv.hex() at the worker. App's /blob handler now just returns row.iv as-is — the previous defensive bytes-to-hex check was masking the real bug. Existing rows written before this fix still carry the "\x..." prefix and need to be reprocessed (delete + POST /process).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
The worker was writing `os.urandom(16)` (raw bytes) into the `SavedPackageData.iv` column, which is declared as `String(255)` in db.py:17. SQLAlchemy/psycopg2 serialize bytes-into-text using PostgreSQL's BYTEA literal — `\x` followed by the hex bytes — and that string flowed unchanged to the client through `/blob`'s JSON response (`"iv": "\\x5d05..."`).
The frontend then handed that to `decryptPackageBlob`, which interpreted it as a hex IV. The leading `\x` is not valid hex, so AES-CBC decryption either threw or produced garbage. The loading page hung forever — backend showed `PROCESSED`, but the data fetcher never resolved, so the UI stayed on the processing screen.
Spotted because PR #74's first real package finished server-side but the UI reported it as still processing — a curl on `/blob` revealed the malformed IV.
Fix
No frontend change. The frontend is correct — it expects a hex string and the server should always provide one.
Migration
Existing rows written before this fix still carry the `\x` prefix in the `iv` column and will continue to fail decryption. To recover them:
```bash
scripts/reprocess.sh ""
```
Reprocessing deletes the bad row + S3 blob and re-runs the worker, which now stores a clean hex IV.
I won't backfill — there's only one such row in production right now (the test package from the Fargate validation), and reprocessing it is a one-liner.
Test plan