On 18 Nov 2021, at 19:48, ste...@eissing.org wrote: > How would you feel about adding mod_tls > (https://github.com/abetterinternet/mod_tls) as an experimental module to > Apache httpd?
Having more choice is excellent. > 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) Client certs is a must for me. I know that they’re political, but my clients in finance don’t care. > - 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, I lean towards adding it as an httpd subproject at this level: https://svn.apache.org/viewvc/httpd/ This frees you from all the complexity around experimental bits of httpd compared to fully supported bits. This means that practically, it can be packaged through channels like EPEL until it becomes stable, at which point the distros will pick it up. It also insulates us against external dependencies like rust. Languages wax and wane, should a rust2 coming along, or another language called oxide that’s better, we’re not left with aging code in our codebase. This is a problem that APR solves for us for operating systems. Regards, Graham —
