search

socketry / nio4r

Cross-platform asynchronous I/O primitives for scalable network clients and servers.
Other
964 stars 85 forks source link

Increase size of RSA keys to 2048 bits #199

Closed boutil closed 5 years ago

boutil commented 5 years ago

1024 bit keys are considered insecure by newer OpenSSL

tarcieri commented 5 years ago

@boutil the Ruby 2.6 failures look unrelated, and like some sort of Travis CI environmental issue. Mind adding rvm: 2.6 to allowed_failures here:

https://github.com/socketry/nio4r/blob/master/.travis.yml#L24

ioquatix commented 5 years ago

I will take a look at this issue now.

tarcieri commented 5 years ago

Looks like this broke the build on master?

ioquatix commented 5 years ago

It's working for me locally but maybe not on travis. Still working through the OpenSSL issues.

ioquatix commented 5 years ago

So, I've been playing around around with the unwritable socket specs for SSL. It's the only spec that's currently failing.

It seems to me it would be very hard to make this reliable.

Because if it's unwritable, as soon as the internal buffer is flushed, it would become writable. Of course, the point of handling writable events is non-blocking writes. So, it's very time dependent.

One aspect of this is using a localhost socket. If the receive end is full and the sender is also full, I assume the OS can accurately determine that no additional data can be sent.

Maybe I'm misunderstanding how the buffering should work in this case. Perhaps you can give me your thoughts about how it should work?

tarcieri commented 5 years ago

The TLS buffering situation is rather complex due to features like renegotiation / rekeying. If the test was previously covering what is effectively an OpenSSL < 1.1 implementation detail, it should probably be replaced/removed.

ioquatix commented 5 years ago

In async, rather than testing specific state changes, e.g. becoming readable, I assume that what the user is interested in is actually reading and writing data.

So, I made specs that do things like "write X bytes, then read X bytes, are they the same". This can incorporate elements of readability, writability, and non-readability/writability above. Although it's hard to test specific events, we can test the actual use cases related to transmitting data.

I guess at the lower level, it's pretty tricky as you say, due to changing implementation details, which affect the state transitions that occur. They may not be deterministic either.

That being said, nio4r does have some really good specs to test the low level event transitions, and I respect the need for some specs like that. I'll try to get all the specs passing, but the more reliable they are the better it's going to be going forward. Even the implementation details of sockets on darwin was causing lots of issues.. :/

tarcieri commented 5 years ago

The existing test suite has been an ongoing pain point. If you have ideas how to improve it, by all means. What you're describing (something a bit more scenario-based) makes sense to me.