limit to Python <= 3.12 - for now - until all our required deps support Python 3.13 free-threaded ABI

[electroglyph]

Right now the only thing stopping autobahn from working in Python 3.13 free-threaded is the hard requirement on cryptography (which currently doesn't work in free-threaded due to CFFI not being thread-safe).

after making that package optional autobahn works great in Python 3.13t

[oberstet]

thanks for your notes, and for the information contained, such as: reason of cryptography not working (yet) on python 3.13 is CFFI "not thread-safe", the free-threaded issue. I see - wasn't aware, seems tricky, but I'm sure they will fix it .. at some point ..

now, rgd making cryptography optional in autobahn: that is of course a question/wish, lets discuss and share opinions.

my opinion: security is essential / non-negotiable, in general (IT), and in WAMP, and cryptography is used directly/indirectly in many places in autobahn, so making cryptography optional effectively means:

make security optional

---

The alternative is not only fine, but desirable in my eyes:

If a user can not or does not want to deploy cryptography (the Python package), that means the user can not use autobahn.

A system turned off is still secure, thus preferable to an insecure, online system.

[meejah]

Note that free-threaded Python is still "experimental" and I personally wouldn't expect that to change until extremely-vital projects like "cryptography" are also supported. There's also an approximately 40% overhead for single-threaded programs, so I wouldn't expect any (positive) impact on autobahn / crossbar performance quite yet.

Related:

• https://github.com/pyca/cryptography/issues/10806
• https://github.com/python-cffi/cffi/issues/126

[oberstet]

thanks @meejah for the explanations and the links! I guess it's obvious this runs deeper (e.g. curl Python package and what), and it'll take time and proper effort on multiple fronts - and I totally agree - only gut feeling, but - that the implications on performance will be a big unknown, time will tell, but ..

[oberstet]

consequently, until that happens, and since cryptography is required for autobahn, we should

limit Python <= 3.12 (for now)

https://github.com/crossbario/autobahn-python/blob/7bc85b34e200640ab98a41cfddb38267f39bc92e/setup.py#L265

[electroglyph]

cryptography is absolutely not required for autobahn. i'm using autobahn right now in a free-threaded program without cryptography, hence the suggestion =)

Every user of Evennia (https://www.evennia.com/) falls into the cryptography-optional camp. I understand your reasoning, but I'm using it to provide a local websocket connection (I can't physically open internet facing ports).

Is there a simple way to make cryptography install by default, but have a package option that deselects it?

[oberstet]

cryptography is absolutely not required for autobahn

yes, it is:

https://github.com/crossbario/autobahn-python/blob/7bc85b34e200640ab98a41cfddb38267f39bc92e/setup.py#L236

if you mean, "required" in the hard technical sense beyond

• tagged releases in this GitHub repo or
• ready made and tested Python modules (like what setup.py spills out etc) or installation packages (eg on PyPI) we maintain/publish

the no, I agree, not required in that sense:

Autobahn is OSS, so you can take the code and do what you want (roughly) - if that means "no cryptography" for you, that is totally fine and you will have reasons or requirements or what for doing so! all good & cool!

sidenote 1: historically, our official Autobahn Python package could be installed without TLS, encryption and cryptography as one Python package dist option. This resulted in massive amounts of work on our side (keeping up that usage option), and hence we started to reduce the crazy amount of combinations of options and target environments Autobahn supports.

sidenote 2: personally, my stance is: full, state-of-the-art encryption, cryptography (in the general sense, and in the Python package sense) and TLS v1.3+ is absolutely prio 1 for Autobahn, and making it optional is additional work for no gain.

[ngoldbaum]

FWIW I'm actively working on getting a version of cryptography working with the free-threaded build: https://github.com/pyca/cryptography/pull/12555

[oberstet]

the modernized and updated CI/CD now tests and builds on cpy314 too! https://github.com/crossbario/autobahn-python/actions/runs/18241551647

and the autobahn websocket testsuite tests cpy314 on twisted & asyncio with all tests 100% green https://github.com/crossbario/autobahn-python/actions/runs/18241551654

[ngoldbaum]

This issue is about free-threaded Python - I don't think you set up tests for that unless I'm missing something in your links.

Cryptography 26.0.0 supports free-threaded Python 3.14, so you should be able to try that. I would re-open this issue until someone does that.

[oberstet]

free-threaded Python - I don't think you set up tests for that

that's true, but why would we want to - here in autobahn-python ?

IMO, the python run-time implementation should cover, and maybe upstream cryptography, but why would autobahn cover free-threaded with tests?

[ngoldbaum]

Because otherwise your users might hit issues that are only possible under the free-threaded build. In particular, behaviors that happen when using the library in threads.

IMO all libraries that want to claim they fully support Python 3.14 should explicitly test both builds. While it is true that thread safety issues that are possible on the free-threaded build are also almost always possible on the GIL-enabled build, in practice it's much easier to trigger thread safety issues without a GIL, since the default thread switch interval in CPython makes it very unlikely that many thread safety issues will trigger, in practice.

That said, I've never looked closely at this library. If you think any possible issues aren't worth adding testing for, you would have more context than me.

[oberstet]

well, it is a deep rabbit hole, and at the user level, there is no easy answer we can give (as Autobahn|Python), because we support:

• CPython with CPyExt and PyPy with CFFI
• Linux epoll, *BSD kqueue and Windows IOCP
• Python stdlib asyncio and Twisted reactors

if you multiply that, there's a lot that can go wrong;)

finally, Autobahn|Python is mostly pure Python, but - optionally - also a bit of native code for acceleration (mainly for CPython): https://github.com/crossbario/autobahn-python/tree/master/autobahn/nvx

this is pretty modern code, using CFFI, not using writable global data, so I'd say "low risk" wrt GIL / free-threaded

ultimately, the main issues will already come from above matrix below Autobahn|Python!

finally, I should stress: these potential issues are then only arising when a user decides to go free-threaded Python and includes Autobahn|Python to talk WebSocket or WAMP from that very user program

for Crossbar.io, we don't need or run free-threaded flavors of either CPython or PyPy - Crossbar.io is designed for process-based scale-up with efficient IPC, so the whole "threading" nightmare disappears while still allowing to reap benefits of many cores (SMP)! I know, I tested scalability under massive real-world load on many core SMP boxes, like e.g. using >64 CPU cores.

[oberstet]

fwiw, I've added a new docs page https://github.com/crossbario/autobahn-python/pull/1678/files#diff-f0eb8ffd2b5984f022630105f603a3c1ff5b51791a41dbce1c886cc2001f36ac - will be released & published with v25.9.1