You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Implementations MUST NOT negotiate RC4 cipher suites.
I agree with that, but I'm not sure how this would fit into the semver picture, as it's not really an API change itself, but still has the possibilty of breaking connectivity of naive implementations that use the default cipher suite (when the other end of the connection is ancient). Further, the issue is complicated because apparently, our TLS client's ciphers option was never documented.
Semver says, we can issue deprecation warnings in a semver-minor, and I think the best course of action would be to document the pending RC4 removal in the release notes and the docs, and finally remove the cipher in 2.0.0. Does this sound reasonable?
Also to note: RC4 will not be entirely deprecated unless OpenSSL drops support for it. It just won't be available for negotiation using the default settings.
Activity
silverwind commentedon Feb 14, 2015
Also to note: RC4 will not be entirely deprecated unless OpenSSL drops support for it. It just won't be available for negotiation using the default settings.
silverwind commentedon Feb 14, 2015
Maybe I'm blowing this a bit out of proportion, but I think the removal of RC4 from the default ciphers should happen in a
semver-minorat least.indutny commentedon Feb 14, 2015
I suggest it to be
semver-minor.silverwind commentedon Feb 15, 2015
Alright,
semver-minorbe it then.Fishrock123 commentedon Feb 15, 2015
Does this mean #826 is
semver-minor?silverwind commentedon Feb 15, 2015
Yes, please tag it.