Possibly no strong opinions? +1 from me anyway. How hard is it going to be to test in Travis?
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. > > >
