_socket.ALG_SET_PUBKEY is a wrong internal value from libkcapi (changed in 2022)

[mattip]

Bug report

Bug description:

import _socket
print(_socket.ALG_SET_PUBKEY)

The output is 6, but the value has been 7 since 2022. This is an internal interface inside libkcapi, I could find no reason it should be included in CPython. This came up when correcting a typo in PyPy pypy/pypy#5594.

CPython versions tested on:

3.14

Operating systems tested on:

Linux

Linked PRs

• gh-158285: Deprecate socket.ALG_SET_PUBKEY, ALG_OP_SIGN and ALG_OP_VERIFY #158382

[MannXo]

Changing it to 7 wouldn't fix it. ALG_SET_PUBKEY, ALG_OP_SIGN and ALG_OP_VERIFY were never in mainline Linux, only in libkcapi's own header, so the "Linux 4.8" comment in Modules/socketmodule.h is wrong. v4.8's if_alg.h stops at ALG_SET_AEAD_AUTHSIZE (5).

Mainline has since taken both numbers. 6 is ALG_SET_DRBG_ENTROPY (5.10), and 7 is ALG_SET_KEY_BY_KEY_SERIAL (6.2). Since mainline headers never define ALG_SET_PUBKEY, CPython always falls back to 6, so on 5.10+ it is really the DRBG entropy option.

With no correct value to give them, I'd deprecate all three for removal. Or would you rather drop them outright, since they never worked against a mainline kernel? Happy to send the PR either way.

[anbv29]

Hi maintainers — I’d like to contribute to “_socket.ALG_SET_PUBKEY is a wrong internal value from libkcapi (changed in 2022)”. I have Python experience and can take a focused approach: reproduce the report, trace the affected module, add a regression test for the stated behavior plus a nearby edge case, then implement the smallest compatible fix while keeping the public API and existing behavior stable. I’ll run the repository’s relevant test/lint/type-check commands and keep the PR limited to this issue. Would you be comfortable confirming this direction before I open a PR?

[mattip]

@anbv29 are you an AI agent? You just commented on an issue in numpy with very similar language. Please do not spam open source project's issue trackers with offers of help, it just burns out the maintainers that need to read the slop. If you would have read this issue, you would have seen that it is waiting for a maintainer to weigh in on a preferred course of action.

[encukou]

+1 to deprecating, since they could be used in working code.