Closed link2xt closed 4 years ago
@Darkspirit We are happy to disable insecure ciphersuites by default, but simply telling users to switch to plaintext because the only provider available to them is using 1024-bit RSA is not an option. If rustls provides 1024-bit RSA support as an option that could be enabled via .danger()
, we would consider using it, but right now we want to make a release ASAP and can't wait for the whole chain of changes in ring, webpki and rusttls to happen.
Oh, that's reasonable! I did not comprehend that you've already shipped this regression. But could you merge this as optional feature, please?
@Darkspirit It's getting a bit off-topic, but to clarify the situation: we have a stable version released on Google Play that works for users with 1024-bit RSA server, a beta version with native_tls that also works, and a nightly based on rusttls that doesn't allow them to connect. We can't even ship rusttls-based version to the beta channel as it will make the client unusable for a lot of users at once automatically, forcing them to either stop using the client or switch to plaintext configuration.
But could you merge this as optional feature, please?
async-tls
and async-native-tls
have slightly different interfaces (for example, see the return value of connect
). For async-imap
I used conditional compilation, but it breaks doctests and has other problems like duplicate code because cfg!
doesn't work with different return values in different branches of if
. So I decided not to go this way for async-smtp
. I would like to unify async-tls
and async-native-tls
interfaces first, hopefully merging them into a single repo, with trait-based interfaces. But that also requires coordinating things with async-tls
developers, so it is postponed until we have a release.
tracking https://github.com/async-email/async-smtp/issues/4 to bring back rustls as an option
Removing Rustls or unexpectedly changing the default would cause breakage. Please consider not damaging an ecosystem just because your chat system is fragile to a few misconfigured email servers using 1024 bit RSA. :-/ Please make this optional and at least inform your users that their mail password is transmitted over a connection that doesn't meet security standards so that they can inform their providers on their own.