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

[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

• gh-138252: Add support in SSL module for getting and setting TLS signature algorithms #138269

[picnixz]

It looks like a duplicate of #88974 actually

[ronf]

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?

[picnixz]

I need to think more about this. cc @gpshead

[ronf]

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.

[picnixz]

Thank you!