Repository navigation
Floor duckdb to 1.4.2 so a build cannot land on CVE-2025-64429 - #56
Merged
Merged
Conversation
Nothing in the dependency graph asks for duckdb -- not hotdata, not hotdata-langchain -- so the unpinned install was whatever PyPI served the day the layer was built, and 1.4.0-1.4.1 were current long enough to be baked into a published image. Those skip the return code of OpenSSL's rand_bytes() in the encryption path added in 1.4.0, so a failed generator reads as a good one; 1.4.2 checks it. The server only casts JSONL to parquet over an in-memory connection and never attaches an encrypted database, so the path was unreachable here -- this keeps the scanner's finding from coming back, it does not close an incident. A floor, not a pin, and alongside urllib3's for the same reason: a rebuild today already resolves past it, but a layer cache or a platform without current wheels would quietly drop back. Same floor in the local-dev install line, so a fresh venv cannot reproduce it either.
eddietejeda
requested review from
anoop-narang
and removed request for
a team
October 28, 2026 17:33
![claude[bot]](https://avatars.githubusercontent.com/in/1236702?s=60&v=4){kind=small}
| # its job: nothing at runtime needs it, and its vendored copies of msgpack and | ||
| # setuptools are scanner findings of their own. | ||
| # hotdata` accepts versions with known CVEs. duckdb is floored for the same | ||
| # reason and against nothing: no dependency here asks for it, so an unpinned |
There was a problem hiding this comment.
super nit: The phrase "for the same reason and against nothing" contradicts the next clause (not blocking). The urllib3 reason is that hotdata accepts vulnerable versions. No dependency requests duckdb, so the duckdb reason differs. A reader cannot tell what "against nothing" means. Suggested wording: "duckdb is floored because no dependency here constrains it, so an unpinned duckdb is whatever PyPI served…"
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.
A dependency scan flagged
duckdbin the published image as Critical: "Attacker can abuse unchecked return values" — CVE-2025-64429. The block-based encryption added in duckdb 1.4.0 skips the return code of OpenSSL'srand_bytes(), so a failed generator reads as a good one. Affects 1.4.0–1.4.1; fixed in 1.4.2.Nothing in the dependency graph asks for duckdb — neither
hotdata0.12.0 norhotdata-langchain0.17.0 declares it — so the unpinned install was whatever PyPI served the day the layer was built, and 1.4.x was current long enough to be baked in.A floor, not a pin, next to
urllib3's for the same reason: a rebuild today already resolves to 2.0.0, but a layer cache or a platform without current wheels would quietly drop back. Same floor in the local-dev install line indocs/operating.md, so a fresh venv can't reproduce it either.Exposure was nil.
server/server.pyuses an in-memoryduckdb.connect()only to cast JSONL to parquet — noATTACH, no encryption keys — so the vulnerable path was never reached. This keeps the finding from coming back; it doesn't close an incident. The "Critical" badge is the scanner's, not the CVE's: upstream scores itAV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N.The scanner goes green once this merges and the image is rebuilt and republished.