Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Retire the thrift advisory acceptance from deny.toml, SECURITY.md and STATUS.md once parquet >= 59 is in the lock

Open
  • Is something wrong?
#54 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
25/100
Issue type
Documentation
Clarity
Clearly specified
Activity status
Active
Tech stack
rust
Domain
documentation, release, security

Research direction

This task is blocked by #40. Once it lands, first run cargo tree -i thrift and confirm thrift is absent from the dependency graph. Then update deny.toml, SECURITY.md, STATUS.md, and the new version's Security section in CHANGELOG.md; verify the listed grep and cargo deny check conditions, and close #4.

Written by the indexing model from the issue text.

Description

dependencies documentation

Today — the thrift acceptance is written down in three live places, and
SECURITY.md requires all three to agree:

None is silent: they are listed here, in deny.toml, and in STATUS.md.

Where What
deny.toml:24-37 the fourteen-line reason comment and the { id = "GHSA-2f9f-gq7v-9h6m", … } ignore
SECURITY.md:53-60 the thrift < 0.23.0 bullet under Known, accepted advisories
STATUS.md:13 row 4's note, "thrift CVE-2026-43868 via parquet 58 accepted with reason"

All three are correct today and must stay. The condition for removing
them is written into deny.toml itself — "remove when parquet >= 59 is in
the lock" — and it is not met:

$ cargo tree -i thrift
thrift v0.17.0
└── parquet v58.4.0
    └── datafusion v54.1.0
        └── ballista v54.1.0

Why this wants its own issue — #4 is about the vulnerability and #40 is
about the chain bump that fixes it. This is the third thing: the cleanup
that happens after the bump lands, and the one part of it that is purely
mechanical. It is also the part most likely to be dropped, because it comes
at the end of a nine-crate breaking release when the interesting work is
done and everything is green — and dropping it leaves three documents
claiming an accepted vulnerability the engine no longer has, which is worse
than leaving them stale in the other direction.

There is a second reason to write it down. Until RustSec imports the
advisory, cargo deny check emits two warnings on every run —
unknown-advisory and advisory-not-detected — for this entry. Both are
the designed behaviour of a record filed before RustSec caught up (#40 says
so explicitly), but from the outside they read exactly like a dead ignore.
I mistook them for staleness on 2026-09-19 and went to retire the entry
while thrift was still in the graph. One cargo tree -i thrift settles it,
and this issue exists partly so the next person finds that answer attached
to the task rather than rediscovering it.

Fix — once Cargo.lock carries no thrift entry, in one commit:

  1. deny.toml — delete the comment block and the ignore entry.
  2. SECURITY.md — delete the thrift bullet. Leave the quick-xml and paste
    bullets; they are unrelated and still live.
  3. STATUS.md — drop the clause from row 4's note, keeping the rest of the
    row intact.
  4. Close #4, whose done-when this completes.

Do not touch CHANGELOG.md:247. That entry records what a released
version shipped with, and it was true when it shipped. The removal belongs
in the new version's Security section as a line saying the acceptance is
gone because parquet 59 dropped thrift — not as an edit to history.

Done when

  • grep -rn 'GHSA-2f9f-gq7v-9h6m\|CVE-2026-43868' . --exclude-dir=target
    returns only the CHANGELOG.md entries for already-released versions.
  • cargo deny check passes with no unknown-advisory or
    advisory-not-detected warning — their absence is the proof the entry
    is gone rather than merely unmatched.
  • cargo tree -i thrift reports nothing in the graph.
  • The new version's CHANGELOG has a Security line recording the removal.
  • #4 is closed.

Blocked by #40 (the Ballista 55 / DataFusion 55 chain bump). Nothing here
can start before that lands; once it has, this is an hour's work and a good
first contribution.

Dominant language
Rust
Stars
1
Forks
2
Avg merge
1d 11h
Merged PRs (30d)
7

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from vyncint/oxidelake

All issues in vyncint/oxidelake

Similar issues

More Rust issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.