vavallee/bindery v0.5.2

on GitHub

Security & hardening

Followed up v0.5.1 with a gosec audit pass. One HIGH-severity finding was real; the rest were false positives (taint analysis couldn't see input validation). Fixed the real issue and tightened two adjacent MEDIUM items.

Fixed

• Remote filesystem deletion via book update (HIGH). PUT /api/v1/book/{id} previously accepted a filePath field and wrote it to the book record unchecked. A caller could then trigger DELETE /api/v1/book/{id}?deleteFiles=true (or DELETE /api/v1/book/{id}/file) to run os.RemoveAll on that path — unbounded by the library dir. When BINDERY_API_KEY is unset (a warn-only configuration) this is unauthenticated. filePath is now omitted from the update schema; it remains internally-set by the importer after a successful grab.
• Multipart upload error response. /api/v1/migrate/csv and /api/v1/migrate/readarr already capped body size via http.MaxBytesReader, but passed nil as the ResponseWriter, so oversize requests surfaced as a generic 400. They now pass w, so oversize uploads receive a proper 413 Request Entity Too Large.

Changed

• Backup directory (<data>/backups) is now created with mode 0700 instead of 0755. SQLite snapshots there may contain indexer/client credentials in plaintext rows; only the bindery process should read them.
• Library and audiobook directories created by the importer are now 0750 (was 0755). Host users needing read access should run bindery with a matching UID/GID (standard PUID/PGID pattern used by Readarr/Sonarr containers).