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. 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. Clayton Daley On Thu, Jul 7, 2016 at 2:50 PM, Glyph Lefkowitz <gl...@twistedmatrix.com> wrote: > In the past, we've been very conservative about updating to require new > versions of pyOpenSSL and cryptography. > > Right now we have a patch, <https://github.com/twisted/twisted/pull/146 > > (<https://twistedmatrix.com/trac/ticket/8441#comment:1>), that I'd like > to just land. However, it establishes a dependency on a new version of > pyOpenSSL, which transitively establishes a dependency on a new version of > Cryptography. > > Generally, my thinking has evolved over the last few years to think that > security dependencies like this should move fast, especially on projects > (like pyOpenSSL and cryptography specifically) that don't maintain "stable" > branches which do security patch-releases. > > In this specific case, the fix is not urgent; as it turns out, the > netscape SPKI APIs actually *do* do the desired thing, which is just > hashing the DER bytes of the key. (At the time I made the change to use > Netscape SPKI, I thought it might be including somet other junk in the > hash; we just lucked out here.) It's just a gross API for doing it which > we should stop using now that better APIs have been exposed to do the same > thing. > > However, it bears discussing - what are the things that hold us to older > versions of pyOpenSSL and cryptography? Is there any good reason *not* to > move our version pins forward whenever there's a new API or feature that > we'd like, even for something simple like this cleanup? > > My default position is "upgrade upgrade upgrade" so if there's not a lot > of interest in this discussion I'll probably just land the PR in question > as-is. > > Thanks all, > > -glyph > > _______________________________________________ > Twisted-Python mailing list > Twisted-Python@twistedmatrix.com > http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python > >
_______________________________________________ Twisted-Python mailing list Twisted-Python@twistedmatrix.com http://twistedmatrix.com/cgi-bin/mailman/listinfo/twisted-python