Theo Buehler wrote:
> On Tue, Jun 23, 2026 at 05:14:48PM +0800, Chris Billington wrote:
>> 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?
> 
> Here are the ones that use the specific hack mentioned above:
> 
> devel/codex
> devel/uv
> devel/zizmor
> lang/deno
> lang/gleam
> net/krill
> sysutils/rustic
> 
>> 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.
> 
> It's your call, really. I think both are fine setting USE_NOEXECONLY
> is probably slightly less friction and since rustls now defaults to
> aws-lc, that's probably a bit better tested in the ecosystem.
> Not having USE_NOEXECONLY is of course a plus.
> 
I think I will stick with USE_NOEXECONLY. Delta Chat is quite actively 
developed, so avoiding patches will reduce maintenance burden.