Thanks for the report! As you can probably tell I haven't touched this crate in quite some time and this was more-or-less written for a different age. Nowadays the best solution to this issue is "stop using this crate" with libraries like rustls.

Nevertheless I'll try to do what at least I think is reasonable here. In #33 I'm going to deprecate the safe versions of functions and replace them with unsafe equivalents. That means the functionality is all staying but it's #[deprecated] to warn-on-use. I don't think an 0.2 of this crate is going to happen so it's kind of the best option available being stuck on 0.1. This will still require all users of this crate to update their own usage but that was sort of inevitable anyway.

Thank you so much, @alexcrichton -- I started on the RUSTSEC advisory and I'll include this information once the crate publishes.

FWIW, I'd be happy to tackle the maintenance of the crate if you'd like -- I suspect there will be a need for this crate for a few more years in some obscure cases that involve communication with obsolete systems.

That'd be very helpful, thank you! I've added you as a collaborator now. If you're ok with it I'll still hold on to the publish rights for a version or two (if necessary), but I'd be happy to add you as well to that in the future.

(no offsense meant, I just don't know much about you so would prefer to take things slowly here)

@alexcrichton no problem, completely understandable.

I suspect there will be a need for this crate for a few more years in some obscure cases that involve communication with obsolete systems.

This crate is a dependency of rustls-native-certs (a default dependency of hyper-rustls) and native-tls (a default dependency of reqwest). So this is not an obscure case; a large fraction of projects containing http client code are indirectly using it.

$ cargo new --lib test_tls; cd test_tls; cargo add reqwest; cargo tree -i openssl-probe
openssl-probe v0.1.6
└── native-tls v0.2.12
    ├── hyper-tls v0.6.0
    │   └── reqwest v0.12.12
    │       └── test_tls v0.1.0 (/home/eric/work/play/test_tls)
    ├── reqwest v0.12.12 (*)
    └── tokio-native-tls v0.3.1
        ├── hyper-tls v0.6.0 (*)
        └── reqwest v0.12.12 (*)

$ cargo new --lib test_tls; cd test_tls; cargo add hyper-rustls; cargo tree -i openssl-probe
openssl-probe v0.1.6
└── rustls-native-certs v0.8.1
    └── hyper-rustls v0.27.5
        └── test_tls v0.1.0 (/home/eric/work/play/test_tls)

So this is not an obscure case; a large fraction of projects containing http client code are indirectly using it.

Agreed -- to clarify, I mean that the option of moving to rustls is not available to all current users of OpenSSL, as rustls does not support certain older TLS and SSL standards that are still available in certain OpenSSL builds.