Vladimír Čunát

Safe? I believe, there's no (IETF-)standardized way to do ESNI yet, so it's _necessarily_ an experiment that will need some (hopefully minor) tweaks before becoming stable. The IETF consensus seems...

Yes, the number will change, and the DNS record as well. I don't know the plans of implementors (and those who've deployed it already) or even details of the TLS...

They can surely block way faster and simpler than "we" can do widespread deployment (of anything).

Debian doesn't provide -dbgsym for this platform (no idea why). When I build it myself from master on the same machine, the error disappears :-/

No, that cqueues version had this fixed already. And my testing was with this anyway: ``` # apt show lua-cqueues Package: lua-cqueues Version: 20200726-1 [...] ```

This is the same with moonjit 2.1.2. I guess this isn't enough "proof"? ``` (gdb) bt #0 lj_err_msg (L=0x18255adee378, em=em@entry=LJ_ERR_BADLU) at lj_err.c:645 #1 0x0000aaaaaab00180 in lua_pushlightuserdata (L=, p=) at lj_state.c:121...

As I wrote, I can't reproduce the failure when recompiling by hand (so far). Maybe the address layout is sensitive to something that I don't know about.

Line isn't surprising: https://salsa.debian.org/lua-team/lua-cqueues/-/blob/2eb74cf0/src/cqueues.c#L2940

It's the `defined(LUA_JITLIBNAME)` in the condition. Debian naturally assumes that packages built against vanilla lua 5.1 will be usable with luajit, moonjit, etc.

For reference, [luaossl](https://github.com/wahern/luaossl/pull/173) suffers from the very same (except its version is ancient on Debian anyway).