This fixes issue #271 where cargo build fails due to openssl-sys dependency
being pulled in even though the project uses rustls-tls for all TLS connections.
**Problem:**
- The Dockerfile installed `libssl-dev` in the builder stage
- This caused `openssl-sys` to be activated as a dependency
- Users without OpenSSL installed would get build failures:
```
error: failed to run custom build command for openssl-sys v0.9.111
Could not find directory of OpenSSL installation
```
**Solution:**
- Remove `libssl-dev` from Dockerfile build dependencies
- ZeroClaw uses `rustls-tls` exclusively for all TLS connections:
- reqwest: `features = ["rustls-tls"]`
- lettre: `features = ["rustls-tls"]`
- tokio-tungstenite: `features = ["rustls-tls-webpki-roots"]`
**Benefits:**
- Smaller Docker images (no OpenSSL headers/libs needed)
- Faster builds (fewer dependencies to compile)
- Consistent builds regardless of system OpenSSL availability
- True pure-Rust TLS stack without C dependencies
**Affected platforms:**
- Users without OpenSSL dev packages can now build directly
- Docker builds are more portable and reproducible
- Binary distributions don't depend on system OpenSSL version
All tests pass.
Related to #271
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
Dockerfile builder image 1.93-slim is (now?) based on debian trixie (13)
The production runtime image was created based on debian-12 which did
not have the version of libc that zeroclaw was built against and that
caused this error:
[zeroclaw] | zeroclaw: /lib/x86_64-linux-gnu/libc.so.6: version
`GLIBC_2.39' not found (required by zeroclaw)
Upgraded runtime image to debian 13 to solve the issue
