fix: update black to fix ReDoS vulnerability

[B4nan]

Summary

• Addresses Dependabot alert Update development dependencies #65 (medium severity)
• Updates black to ≥24.3.0 to fix CVE-2024-21503 (Regular Expression Denial of Service)
• Added explicit constraint in dev dependencies

Test plan

• uv lock completes successfully
• black version updated to 26.1.0
• CI tests pass

🤖 Generated with Claude Code

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 76.01%. Comparing base (ff61ea0) to head (2c4017d).

Additional details and impacted files

@@           Coverage Diff           @@
##           master     #582   +/-   ##
=======================================
  Coverage   76.01%   76.01%           
=======================================
  Files          42       42           
  Lines        2468     2468           
=======================================
  Hits         1876     1876           
  Misses        592      592           

Flag	Coverage Δ
integration	68.96% <ø> (ø)
unit	64.58% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[B4nan]

No idea if this is correct, feel free to resolve the security issue otherwise.

[vdusek]

No idea if this is correct, feel free to resolve the security issue otherwise.

Isn't this just a false positive, taking into account that this is a transitive dependency of pydoc, and we use pydoc as a dev dependency? Meaning the black is not part of our production package.

Of course, it is completely wrong for pydoc (and its dependencies) to use black (linter & formatter) as a production dependency. But it is what it is...

[B4nan]

Security issues in dev dependencies are also valid, because we use them in our CI where we have various secrets that could leak. But you are right that those issues are less important and often invalid for us. Still, if we can resolve them with a dependency bump, we should do so.

What's the alternative here? I guess waiting for pydoc to update their dependencies? We can surely wait a bit with this, I was mostly testing how claude handles this kind of task, since it will get worse once we include more repositories in those checks.

[vdusek]

Security issues in dev dependencies are also valid, because we use them in our CI where we have various secrets that could leak. But you are right that those issues are less important and often invalid for us. Still, if we can resolve them with a dependency bump, we should do so.

That makes sense, thanks.

What's the alternative here? I guess waiting for pydoc to update their dependencies? We can surely wait a bit with this, I was mostly testing how claude handles this kind of task, since it will get worse once we include more repositories in those checks.

The issue is that pydoc-markdown, which we use for documentation generation, uses docspec-python to parse Python source code, and docspec-python depends on black for parsing. While docspec-python has already updated to a newer version of black, pydoc-markdown is not very actively maintained and still uses an older docspec-python version, which results in the outdated black.

We can try to resolve this as proposed in the PR by explicitly constraining the black version on our side. Hopefully, this won't break anything in the docs generation.