main already has the fix. PR #74 rebased Pyink onto Black v26.3.1 and merged on 2026-04-09, and pyproject.toml on main now reads black==26.3.1.
The newest release on PyPI is still pyink 25.12.0, published 2026-01-02, and that one pins black==25.12.0. So pip install pyink today brings in black 25.12.0, which has two published advisories:
- CVE-2026-31900 — CVSS 3.1 9.8 (
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), fixed in black 26.3.0
- CVE-2026-32274 — CVSS 3.1 7.5, arbitrary file write from unsanitised input in the cache file name (CWE-22), fixed in black 26.3.1
Because the dependency is an exact == pin, users cannot resolve around it — there is no released pyink that accepts a patched black.
To be clear, I am not suggesting the exact pin is wrong. The README explains that Pyink keeps local patches on top of Black and rebases on its latest changes, so an exact pin is the sensible thing for a fork like this. The only issue is that the rebase which carries the fixes has been on main unreleased for about four months.
I came at this from the other end: pip install tabfm[dev] (google-research/tabfm) resolves pyink 25.12.0, and therefore black 25.12.0. Anything else that depends on pyink inherits the same.
Would you be able to cut a release from main? #41 was a similar bump request, so I hope this is a familiar shape rather than a nuisance.
Disclosure: I used an AI assistant while looking into this. I verified the PyPI metadata, the merge date of #74, the main pin, and the advisory records myself.
mainalready has the fix. PR #74 rebased Pyink onto Black v26.3.1 and merged on 2026-04-09, andpyproject.tomlonmainnow readsblack==26.3.1.The newest release on PyPI is still pyink 25.12.0, published 2026-01-02, and that one pins
black==25.12.0. Sopip install pyinktoday brings in black 25.12.0, which has two published advisories:AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), fixed in black 26.3.0Because the dependency is an exact
==pin, users cannot resolve around it — there is no released pyink that accepts a patched black.To be clear, I am not suggesting the exact pin is wrong. The README explains that Pyink keeps local patches on top of Black and rebases on its latest changes, so an exact pin is the sensible thing for a fork like this. The only issue is that the rebase which carries the fixes has been on
mainunreleased for about four months.I came at this from the other end:
pip install tabfm[dev](google-research/tabfm) resolves pyink 25.12.0, and therefore black 25.12.0. Anything else that depends on pyink inherits the same.Would you be able to cut a release from
main? #41 was a similar bump request, so I hope this is a familiar shape rather than a nuisance.Disclosure: I used an AI assistant while looking into this. I verified the PyPI metadata, the merge date of #74, the
mainpin, and the advisory records myself.