Add MAINTAINERS.md file by TheJuanAndOnly99 · Pull Request #390 · finos/symphony-bdk-python

TheJuanAndOnly99 · 2026-05-25T21:48:58Z

This PR adds a MAINTAINERS.md file to the root of this repository as part of a FINOS-wide effort to standardize maintainer signaling across all FINOS projects. An announcement was sent to community@finos.org with the full context, see announcement email here.

How this list was generated

The maintainers were determined from this repository's GitHub settings:

Users with maintain or admin role on the repository
Members of teams with maintain or admin permission

Each entry includes the GitHub username, name, and organization pulled from the user's public GitHub profile. Where name or organization is missing, a *please add ...* placeholder marks where to fill in the value. Email is optional: it is included when the user has a public GitHub email, otherwise the cell is left blank.

If no maintainers were detected automatically (e.g. your repo has no users or teams with maintain/admin role), the table is intentionally empty. Please populate it manually on this branch before merging and email help@finos.org.

What we need from this project's maintainers

Review the list for completeness and accuracy.
Update any incorrect or placeholder values (names, organization) directly on this branch. Email is optional.
Add anyone missing, edit the file in this PR if a maintainer was not automatically detected.
Merge when the list is accurate.

If your project does not need a MAINTAINERS.md for any reason, just close this PR and let us know at help@finos.org.

If this repository should instead be archived (e.g. it is no longer actively maintained or has been superseded), please email help@finos.org instead so we can coordinate the archival with you.

If you already have a MAINTAINERS.md file, you can close this PR. Please update your existing file if needed and place it in the root of the repository.

Multi-repo projects: share one MAINTAINERS.md

If this repository is part of a project with multiple repositories that share (and will continue to share) the same maintainers, you don't need a separate list per repo. Pick one repository (typically the project's main/umbrella repo) to host the canonical MAINTAINERS.md, and on every other repo replace the table in this PR with a short note pointing readers there, for example:

The maintainers of this repository are listed in the main project repository. See list here.

That way maintainer changes only need to be made in one place going forward.

Going forward: keeping the list current

To keep maintainer changes transparent and aligned with open governance:

Any change to the maintainer list must be made via a PR to this file.
If your project's governance requires a vote, document or link to the vote outcome in the PR description or comments.
This gives the community a public audit trail of project leadership over time.

If you have any questions about the format or process, please email help@finos.org.

Thank you for your review!

Signed-off-by: Juan Estrella <juan.estrella@finos.org>

Drop the please-add-email placeholder and label the column Email (optional). Existing addresses are left unchanged. Signed-off-by: Juan Estrella <36825759+TheJuanAndOnly99@users.noreply.github.com>

Semgrep flagged mutable action tags (checkout/setup-python/cache/upload-artifact) across all workflows as a supply-chain risk. Safety flagged aiohttp, cryptography, idna, pyjwt and urllib3 CVEs; bumped cryptography and split aiohttp by Python version (3.14+ drops py3.9 support), and added -i ignores for findings whose fix requires dropping Python 3.9, matching the policy already used elsewhere in CI.

Safety flagged CRLF/smuggling CVEs in aiohttp<3.13.4, idna<3.15, and several PyJWT<2.13.0 issues that weren't yet covered by the CI workflows' -i ignore lists.

idna 3.19 report license as 'BSD-3-Clause' string, not 'BSD'.

… a patch release. (#397) Prepares a patch release so consumers can pull the cryptography>=48.0.1 constraint already merged to main via #390, closing CVE-2026-34180 on downstream Symphony bots that depend on symphony-bdk-python.

Included here so merging this PR leaves main release-ready, rather than needing a second PR before the fix can reach consumers. The constraint fix in finos#390 sat unreleased for five days because the version bump was a separate change (finos#397). The CVEs this PR addresses are live in the released 2.11.3, so the gap matters. Follows the same convention as finos#397: pyproject.toml only. The lock is unaffected, project version is not part of its content hash.

* Raise cryptography ceiling to allow the patched 50.x The current constraint, cryptography>=48.0.1,<49.0.0, cannot resolve to a version free of known CVEs: 48.0.1 CVE-2026-69247 and CVE-2026-69249 49.0.0 CVE-2026-69247 50.0.x clean Both CVEs were published 2026-08-03, before 2.11.3 was released, so every version the released constraint permits is affected. Downstream consumers cannot work around this: anything satisfying the BDK is vulnerable, and anything patched fails resolution. It surfaces as a hard failure in image compliance scanning. This is the second time in eight days the ceiling has blocked a security fix. #397 raised it from <47.0.0 to <49.0.0 for CVE-2026-34180, and it is already stale again. Verified: the full test suite passes on the new lock and identically on the old pin, so this is not masking a regression. cryptography 48.0.1 560 passed, 3 skipped cryptography 50.0.0 560 passed, 3 skipped cryptography 50.0.1 560 passed, 3 skipped (the locked version) poetry.lock regenerated with Poetry 2.4.2; cryptography 48.0.1 to 50.0.1 is the only package change, none added or removed. * Bump version to 2.11.4 to prepare a patch release Included here so merging this PR leaves main release-ready, rather than needing a second PR before the fix can reach consumers. The constraint fix in #390 sat unreleased for five days because the version bump was a separate change (#397). The CVEs this PR addresses are live in the released 2.11.3, so the gap matters. Follows the same convention as #397: pyproject.toml only. The lock is unaffected, project version is not part of its content hash.

* Add MAINTAINERS.md file Signed-off-by: Juan Estrella <juan.estrella@finos.org> * Make maintainer email optional Drop the please-add-email placeholder and label the column Email (optional). Existing addresses are left unchanged. Signed-off-by: Juan Estrella <36825759+TheJuanAndOnly99@users.noreply.github.com> * Update MAINTAINERS.md * Pin GitHub Actions to commit SHAs and fix CVE/license scan findings Semgrep flagged mutable action tags (checkout/setup-python/cache/upload-artifact) across all workflows as a supply-chain risk. Safety flagged aiohttp, cryptography, idna, pyjwt and urllib3 CVEs; bumped cryptography and split aiohttp by Python version (3.14+ drops py3.9 support), and added -i ignores for findings whose fix requires dropping Python 3.9, matching the policy already used elsewhere in CI. * Bump aiohttp, idna, PyJWT minimum versions to fix new CVE findings Safety flagged CRLF/smuggling CVEs in aiohttp<3.13.4, idna<3.15, and several PyJWT<2.13.0 issues that weren't yet covered by the CI workflows' -i ignore lists. * Add BSD-3-Clause to authorized licenses for liccheck idna 3.19 report license as 'BSD-3-Clause' string, not 'BSD'. --------- Signed-off-by: Juan Estrella <juan.estrella@finos.org> Signed-off-by: Juan Estrella <36825759+TheJuanAndOnly99@users.noreply.github.com> Co-authored-by: Thibault Pensec <39826516+thibauult@users.noreply.github.com> Co-authored-by: Thibault Pensec <thibault.pensec@symphony.com> (cherry picked from commit 5480de1)

* Raise cryptography ceiling to allow the patched 50.x The current constraint, cryptography>=48.0.1,<49.0.0, cannot resolve to a version free of known CVEs: 48.0.1 CVE-2026-69247 and CVE-2026-69249 49.0.0 CVE-2026-69247 50.0.x clean Both CVEs were published 2026-08-03, before 2.11.3 was released, so every version the released constraint permits is affected. Downstream consumers cannot work around this: anything satisfying the BDK is vulnerable, and anything patched fails resolution. It surfaces as a hard failure in image compliance scanning. This is the second time in eight days the ceiling has blocked a security fix. finos#397 raised it from <47.0.0 to <49.0.0 for CVE-2026-34180, and it is already stale again. Verified: the full test suite passes on the new lock and identically on the old pin, so this is not masking a regression. cryptography 48.0.1 560 passed, 3 skipped cryptography 50.0.0 560 passed, 3 skipped cryptography 50.0.1 560 passed, 3 skipped (the locked version) poetry.lock regenerated with Poetry 2.4.2; cryptography 48.0.1 to 50.0.1 is the only package change, none added or removed. * Bump version to 2.11.4 to prepare a patch release Included here so merging this PR leaves main release-ready, rather than needing a second PR before the fix can reach consumers. The constraint fix in finos#390 sat unreleased for five days because the version bump was a separate change (finos#397). The CVEs this PR addresses are live in the released 2.11.3, so the gap matters. Follows the same convention as finos#397: pyproject.toml only. The lock is unaffected, project version is not part of its content hash. (cherry picked from commit 487ac1c)

TheJuanAndOnly99 · 2026-05-25T21:48:58Z