Message 263693 - Python tracker

➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author	gregory.p.smith
Recipients	Zooko.Wilcox-O'Hearn, alex, christian.heimes, dstufft, gregory.p.smith
Date	2016-04-18.21:27:30
SpamBayes Score	-1.0
Marked as misclassified	Yes
Message-id	<1461014850.46.0.587174474556.issue26798@psf.upfronthosting.co.za>
In-reply-to

Content
CPython should not attempt make a judgement about the safety of a particular function. We can only document if something has known issues. We should only include things in the stdlib which are either (a) standard or (b) widely used regardless of being standard. Given that librsync and RAR both support BLAKE2 and that it is defined by an RFC, I'd say it should go in. The reference implementation appears to have Apache 2.0 licensed C code would can fall back to when the OpenSSL in use does not include it. PEP-452 seems to address the necessary API changes.

CPython should not attempt make a judgement about the safety of a particular function.  We can only document if something has known issues.

We should only include things in the stdlib which are either (a) standard or (b) widely used regardless of being standard.  Given that librsync and RAR both support BLAKE2 and that it is defined by an RFC, I'd say it should go in.

The reference implementation appears to have Apache 2.0 licensed C code would can fall back to when the OpenSSL in use does not include it.

PEP-452 seems to address the necessary API changes.

History
Date	User	Action	Args
2016-04-18 21:27:30	gregory.p.smith	set	recipients: + gregory.p.smith, christian.heimes, alex, dstufft, Zooko.Wilcox-O'Hearn
2016-04-18 21:27:30	gregory.p.smith	set	messageid: <1461014850.46.0.587174474556.issue26798@psf.upfronthosting.co.za>
2016-04-18 21:27:30	gregory.p.smith	link	issue26798 messages
2016-04-18 21:27:30	gregory.p.smith	create