Theo Buehler wrote:
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.
Thanks!
I couldn't find any Rust ports using USE_NOEXECONLY. Maybe I am grepping
incorrectly?
What would be the preferable approach for a deltachat-rpc-server port?
The patch to use ring is quite minimal: a one-liner to Cargo.toml and 5
replacements to substitute ring for aws-lc_rs features in two Deltachat
source files.
deltachat-rpc-server is a dependency of Parla, a Vala/GTK4 Delta Chat
client.
Regards,
Chris
