On Thu, 7 Jul 2016 at 23:07 Clayton Daley <clayton.da...@gmail.com> wrote:
> I don't object to this specific change (we're on shiny new code), but want > to offer some food-for-thought: > > 1) Is newer really better in cryptography? Heartbleed affected 1.0.1, but > not 1.0.0 and there are a bunch of vulnerabilities that only affect the > newer libraries (https://www.openssl.org/news/vulnerabilities.html). It > even makes sense that the older libraries have been more-thoroughly > tested... so new code may just mean new vulnerabilities. > First of all, newer cryptography and newer OpenSSL are different things. Given that cryptography itself is mostly made of Python and cffi, not C code, I think it's unlikely that a newer version of cryptography is likely to be worse than an older one. Older libraries being "more thoroughly tested" only really applies where a library has a plethora of simultaneous release channels; for most libraries, using older versions just means missing out on any fixes for issues that were found more recently than the release was released. Even regarding OpenSSL, which is a horrible pile of C, it's unlikely that the potential of another *Heartbleed*-like issue is more dangerous than the lack of actual known improvements. 2) How does this impact regulated industries. In healthcare (my current > industry), changing a library (especially cryptography) could mean: > > - An internal review to select a new version of the library > - An internal change management process > - Technical testing (perhaps a 3rd party audit) > - A notification to clients of the change > - Secondary reviews/testing at clients > > The intensity of this process depends on the risk level of the system and > this could be a long and complicated process for some organizations. Seems > like a more deliberate deprecation policy would make it easier to plan > ahead. > Wouldn't all of the above apply equally to the new version of Twisted? I would imagine you could upgrade Twisted and cryptography at the same time, thus only doing one round of testing/review/etc. for both. (Perhaps I'm missing something?)
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python