Skip to content

Add support in SSL module for getting and setting TLS signature algorithms #138252

Closed

Description

@ronf

Proposal:

This feature proposal is a continuation of SSL feature work begun in issues #136306 and #137197. It adds the ability to set TLS signature algorithms for both client and server in the SSLContext class and later query the selected signature algorithms on an SSHSocket, after the TLS handshake is complete. The new methods would look something like:

    ssl.get_sigalgs() -> List[str]:
        """Get a list of TLS signature algorithms available for server validation
           and client authentication."""

    SSLContext.set_server_sigalgs(sigalgs: str) -> None:
        """Set the TLS signature algorithms allowed for server validation."""

    SSLContext.set_client_sigalgs(sigalgs: str) -> None:
        """Set the TLS signature algorithms allowed for client authentication."""

    SSLSocket.server_sigalg() -> str | None:
        """Return the TLS signature algorithm selected for server validation."""

    SSLSocket.client_sigalg() -> str | None:
        """Return the TLS signature algorithm selected for client authentication."""

Links to previous discussion of this feature:

This work was discussed originally in PR #119244.

Linked PRs

Activity

  1. picnixz commented on Aug 30, 2025

    @picnixz
    Member

    It looks like a duplicate of #88974 actually

  2. ronf commented on Aug 30, 2025

    @ronf
    ContributorAuthor

    It looks like a duplicate of #88974 actually

    Agreed - I didn't notice that before filing this issue. However, OpenSSL has changed a fair amount in the 4 years since that previous issue was filed. In particular, it has moved away from passing around arrays of NIDs in favor of passing a list in as a string, with specific punctuation for delimiters and in some cases other flags (like whether to ignore unknown algorithms). The API I proposed here reflects those changes, and differs from some of the suggestions in #88974 in terms of approach.

    That said, there's an open question in my mind another whether to provide a wrapper for SSL_get1_builtin_sigalgs() or not. It currently takes an OSSL_LIB_CTX as an argument, which is not something the Python code does anything with yet. It is legal to pass in NULL to use the default library context, though, so that might be sufficient.

    The main question is where this would appear in the Python SSL module API, since it's not specific to an SSLContext or SSLSocket, so it would probably have to be exposed as a module-level method, and there are very few of those right now. Thoughts?

  3. picnixz commented on Aug 30, 2025

    @picnixz
    Member

    I need to think more about this. cc @gpshead

  4. ronf commented on Aug 30, 2025

    @ronf
    ContributorAuthor

    For now, I'll create a PR with support for only the functions documented above. If we decide to add a function to get the builtin list of sigalgs, I can add code for that before the PR is merged.

  5. added a commit that references this issue on Sep 8, 2025
  6. picnixz commented on Sep 8, 2025

    @picnixz
    Member

    Thank you!

  7. added a commit that references this issue on Sep 9, 2025
  8. added 2 commits that reference this issue on Jul 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

extension-modulesC modules in the Modules dirstdlibStandard Library Python modules in the Lib/ directorytopic-SSLtype-featureA feature request or enhancement

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions