Increase size of RSA keys to 2048 bits

[boutil]

1024 bit keys are considered insecure by newer OpenSSL

[tarcieri]

@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]

I will take a look at this issue now.

[tarcieri]

Looks like this broke the build on master?

[ioquatix]

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

[ioquatix]

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]

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]

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]

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.