> Am 24.11.2021 um 10:57 schrieb Joe Orton <jor...@redhat.com>: > > Possibly no strong opinions? +1 from me anyway. > > How hard is it going to be to test in Travis?
I have a test suite that can be added to our test/modules. Then we need to bring the rust tool chain into the test image and checkout/create the librustls. I can start a docker image to see what that needs. Kind Regards, Stefan > > On Wed, Nov 24, 2021 at 10:46:03AM +0100, ste...@eissing.org wrote: >> Coming back to this. Since there was no feedback on my post: are people >> just too occupied/opposed/not interested? >> >> Curious, >> Stefan >> >>> Am 18.11.2021 um 18:48 schrieb ste...@eissing.org: >>> >>> How would you feel about adding mod_tls >>> (https://github.com/abetterinternet/mod_tls) as an experimental module to >>> Apache httpd? >>> >>> For people who have not followed that development: >>> - it is a TLS 1.2/1.3 implementation based on rustls, >>> https://github.com/rustls/rustls >>> - the C API is rustls-ffi, found at https://github.com/rustls/rustls-ffi >>> - it is itself written in C, linking all the Rust things from the >>> rustls-ffi library >>> - it does not bring any Rust into our code base >>> - functionality wise, it is a clear subset of what mod_ssl offers via >>> openssl >>> (e.g. no client certificates now and not as tweakable - at least for now) >>> - it can be co-loaded and co-used with mod_ssl on different ports or >>> front-/backend roles >>> - performance-wise, according to my plain vanilla tests, it is on par with >>> mod_ssl >>> >>> The decision to offer it downstream is of course then made by the distros, >>> as usual with experimental modules. And if and how it is then used rests >>> with the users. It is an offered alternative for people. >>> >>> What would be the benefit to the project? >>> - we offer people an alternative. If they feel the memory safety that Rust >>> offers is important to them, they can do it with Apache httpd for the TLS >>> stack. >>> - we could see how people react to this and adapt our TLS offering >>> accordingly. It being experimental, we remain free to change it. Or remove >>> it again. >>> >>> Organizational Things: >>> - the development was done by myself >>> - the work was sponsored by the ISRG (https://www.abetterinternet.org), the >>> org behind Let's Encrypt, as part of they "memory safety" initiative >>> (https://www.memorysafety.org) >>> >>> >>> Feedback appreciated, >>> >>> Stefan >>> >>> PS. On a more personal note: >>> The way this project turned out was a clean separation between C and Rust. >>> The API offered by rustls-ffi is colored by Rust's immutability/borrowed >>> memory concepts, but there is nothing Rust special the C code needs to do. >>> It remains C code. It remains in our core competence. >>> >>> Working with the rustls people has been nice and productive. The only thing >>> I can report is that they come from the client TLS side and specific server >>> needs require some explaining. There are things we can offer to them here. >>> >>> There are a lot of political things going on right now around OpenSSL and I >>> definitely want to stay out of that. Again, we can offer this without >>> having to switch ourself. Even better, customers can use this without >>> needing to switch completely, as it co-exists. I think that fits into the >>> concepts our server is designed with. >>> >>> Thanks for your time. >>> >> >
