Michael Schlenker

The 'fail close, so no security issue' argument is only correct if the verify is set to `False`. If the verify is set to a subset of the global CAs...

The clear method in _ConfigurableSession() assumes that a clear() on its superclass (dict) would call __delitem__, but it does not. So the session stays in persistent storage. This is insidious...

yes. Its the same issue just described differently.

@amol No, it does not, as beaker.crypto.noencryption sets have_aes=False and the check in session.py checks for self.encrypt_key and have_aes, so the exception will still be raised in the same situation....

pyopenssl has the code for basic cert verification. Would be trivial to port to cryptography. #1660 has some basic code to do it and allow callbacks too. It is not...

The code is probably too simple to handle all the tricky details in RFC 5280. Especially the `_is_root_cert()` and `_get_issuing_root_cert()` code is naive and will probably fail miserably for the...

@danetrain Sorry for confusing. Basically if you pass a 'certificate chain', why do you need to search for the root CA with `_get_issuing_root_cert()` ? `cert_chain[0]` should be the root CA...

Motivation is three part: a) Cannot configure the CCM variants b) Looked at the Twisted API for cipher suites and it is broken due to not understanding the existing API...

Hi @tiran yes, agreed that it should be done on the OS level usually and that TLS 1.3 ciphers are great and all that. I basically ship a whole python...

If you have a SSLContext, you can set the appropriate option: ```python SSL_OP_NO_RENEGOTIATION = 0x40000000 ctx.set_options(SSL_OP_NO_RENEGOTIATION) ```