Hi Simon,
> Am 12.05.2022 um 11:28 schrieb Simon Studer <simon.stu...@netnea.com>:
>
> Hi everyone,
>
> When I read about Apache's use of rustls I thought of this thread again.
>
> For mod_tls, the module itself was written in C linking to the rustls-ffi. I
> have been wondering if it would be desirable to implement the modules
> themselves in Rust as well and how you would go about doing that. This is
> something I have superficially looked into in the past but never really
> followed through with.
>
> I looked around and found https://github.com/majorz/apache2-rs which has been
> inactive since about 7 years ago. There are also a number of forks which are
> more recent but also appear to be inactive and left in an early development
> state. There appears to be one fork that has only just been worked on
> recently with minor tweaks but it is still the same for the most part.
When I started the work on mod_tls, I was pointed to that abandoned project as
well. The main issue I see in this approach is that one does "duplicate" Apache
APIs and those duplications do not follow any updates/improvements that the
server will do over time. This may lead to various breakages, even when the API
is extended in a C-backward compatible way. This happens quite often in the
2.4.x release line.
Examples of that:
- Adding an enum: if a new HTTP status comes up, the sever adds a definition to
its enums, but the "pub enum Status {...}" (as defined in
https://github.com/majorz/apache2-rs/blob/master/src/httpd.rs) would not
follow. The Rust language runtime will panic() if it encounters an enum not
properly defined.
β the wrappers in https://github.com/majorz/apache2-rs/blob/master/src/ffi.rs
do not follow either and will not account for added fields. Adding fields
happens regularly. The "wrong" size will most likely be problematic in the
Copy/Clone traits
To control that, all these definitions would best be done as part of the Apache
httpd project. That would require a serious build-up of Rust competence among
the core developers. It is doubtful, if the existing team is interested in
that. Of course, Rust people who want to make a long-term commitment in the
project would not be turned away. But so far, I do not see any.
Beyond the pure writing code stuff, the target platforms would need to be
managed. Apache runs on architectures which are not supported by Rust.
Also, feedback from linux distributions I got (those may not be representative)
is that they are hesitant to include more Rust components. I have heard of none
that has picked up mod_tls in their package distribution. That hesitation seems
mainly to stem from the fact that Rust regularly re-invents itself and requires
everything to update to the current state of languages and crates. Those are
mostly in 0.x.x versions and APIs do change regularly.
This means that updating a Firefox requires a Rust updated which requires an
update of crates which then might mean other Rust packages will no longer
compile and one has to update them too, if indeed such an update for the
Firefox Rust version is available. etc. etc. This conflicts with any LTS
distribution model.
tl;dr
The update/backward compatibility/dependency handling of Rust and the *nix
world where Apache contributes too are different in vital aspects. This makes
delivery of Rust based modules there difficult. If you do a module just for
your own/organization, this might be fine.
> Recently, I have started to implement something similar, mostly to get some
> familiarity with the process of using Rust's bindgen tools. The approach I
> chose is somewhat different as I generate the FFI with bindgen on the fly
> during the build process. The project is located here:
> https://github.com/studersi/apache-rs. I have not implemented any
> abstractions yet that are more idiomatic to Rust and stuck to the FFI
> generated by bindgen for now. I will likely add such abstractions later to
> get the most out of Rust's safety guarantees.
>
> Is anyone else looking into this or maybe even the owner of one of the other
> projects? Any other thoughts or comments are welcome as well :-)
Rust is an excellent language. The weakness I see is that no one commits to any
long-term stability. If you use Rust, you must account for language and crate
changes which will force you to upgrade at any time. If a crate fixes a CVE, it
means you have to re-build your Rust component using the recent versions of
everything.
I hope this explains a bit the reasons behind writing mod_tls in C and linking
Rust from a (sadly static) library.
Kind Regards,
Stefan
>
> Best,
> Simon
>
>
>
>
> On 8/21/20 01:00, Wendell Hatcher wrote:
>> Golang!! πππ
>>
>> Wendell
>>
>>> On Aug 20, 2020, at 6:58 PM, Nick Kew <n...@apache.org> wrote:
>>>
>>> ο»ΏOn Thu, 20 Aug 2020 21:59:50 +0200
>>> Simon Studer <simon.stu...@netnea.com> wrote:
>>>
>>>> Hi everyone,
>>>>
>>>> Recently, I was wondering which programming language should be used
>>>> for new Apache httpd modules.
>>> Whatever suits the module's developer and task.
>>>
>>> The C API has a stability promise: if you use it, your
>>> module will continue to work with (at least) future 2.4.x
>>> releases. That give you C or any language with C linkage.
>>> If you deviate from the API, you're on your own.
>>>
>>> Alternatives that (broadly speaking) wrap the C API are also
>>> possible: see for example mod_perl and mod_lua.
>>>
>>> --
>>> Nick Kew
>
