On Tue, Jun 23, 2026 at 04:35:55PM +0800, Chris Billington wrote: > When trying to produce a port for deltachat-rpc-server 2.53.0, I stumbled on > a problem with the aws_lc_rc crate which is used for TLS.
If you want to keep using aws-lc, this is the approach existing ports use. # aws-lc-sys has constants in .text # https://github.com/awslabs/s2n-bignum/pull/242 .if ${MACHINE_ARCH} == "amd64" USE_NOEXECONLY = Yes .endif The PR has been merged but it still needs to trickle into the ecosystem. > The port builds two executables deltachat-rpc-server and deltachat-repl > which reliably crash when making a TLS connection: > > Thread 2 "tokio-rt-worker" received signal SIGSEGV, Segmentation fault. > 0x... in aws_lc_0_41_0_curve25519_x25519base () > > I suspect this is similar to the exec-only violations which were encountered > with the ring-0.16 crate, where key algorithms making use of > assembly-language code are attempting to read from an executable-only > region, /usr/local mounted with wxallowed. This led to the making of the > security/rust-ring port maintained by tb@. Yes. It's the same issue. It will eventually fix itself but needs some more patience. Since aws-lc is much faster evolving than ring, an analog to rust-ring is something I'd like to avoid. > I managed to patch deltachat-rpc-server to use ring-0.17 instead of > aws_lc_rs, and this now connects reliably with TLS. I will continue to test. That's the other option. I think using USE_NOEXECONLY for amd64 is the approach with less friction for now.
