On Mar 25, 2014, at 7:03 PM, Nick Coghlan <ncogh...@gmail.com> wrote:
> > On 26 Mar 2014 08:35, "Antoine Pitrou" <solip...@pitrou.net> wrote: > > > > On Tue, 25 Mar 2014 23:09:45 +1000 > > Nick Coghlan <ncogh...@gmail.com> wrote: > > > > > > Alternative: selectively backport particular APIs > > > ------------------------------------------------- > > > > > > An instinctively minimalist reaction to this proposal is to only backport > > > particular APIs in the affected modules that are judged to be "security > > > critical". However, this ends up providing a worse end user experience, > > > as well as a worse developer experience. > > > > > > For end users, the selective backporting approach means learning not only > > > the legacy Python 2.7 API and the current Python 3 APIs, but also the > > > hybrid API created by the selective backporting process. > > > > I think this is a strawman, since you are also advocating for a > > "feature detection" approach to writing cross-version code. It is > > already required, actually, if wanting to write code compatible from > > 3.2 to 3.4 (for example, SSLContext exists in 3.2 but > > create_default_context appears in 3.4 while OP_NO_COMPRESSION appears > > in 3.3). > > > > I would much rather selectively backport a minimal set of APIs than the > > whole range of ssl APIs. There are things there (RAND_bytes, > > RAND_pseudo_bytes) that are not even useful for network security, or > > only in a rather uncommon manner (such as channel bindings). > > Yeah, I think this is a valid point, and, as Guido noted, we also want the > option to skip backporting things if they depend on other aspects of Python 3 > that we decide can't be backported. > > So a feature-by-feature decision making process actually does make more sense > than a blanket exemption. > > Looking at the ssl module, just about the only thing that wouldn’t be helpful to have backported is the rand functions that AP mentioned (and those mostly because everyone should just use os.urandom for everything ever). The NPN stuff isn’t important for security related stuff either though it’d probably be more work to rip it out and more disruptive as well. Looking at the hmac module, the only thing that really matters for a backport would be the constant time compare. Lokoing at hashlib, the guaranteed and supported algorithms would be nice to have but not really security sensitive. Adding pbkdf2_hmac would be really nice for the security of web services though. Looking at os.urandom, back porting the lazily opened and held file descriptor would be a nice to have, but not strictly required. (Not sure if that would be considered a backwards incompat change). Nothing in random.py really stands out to me looking at it’s docs. > Cheers, > Nick. > > > > > Regards > > > > Antoine. > > > > > > _______________________________________________ > > Python-Dev mailing list > > Python-Dev@python.org > > https://mail.python.org/mailman/listinfo/python-dev > > Unsubscribe: > > https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com > _______________________________________________ > Python-Dev mailing list > Python-Dev@python.org > https://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > https://mail.python.org/mailman/options/python-dev/donald%40stufft.io ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
