Author pstch
Recipients Jeremy.Hylton, Trundle, alex, benjamin.peterson, berker.peksag, brett.cannon, daniel.urban, dmalcolm, eltoder, eric.snow, georg.brandl, gregory.p.smith, inada.naoki, isoschiz, jcon, mark.dickinson, meador.inge, nadeem.vawda, ncoghlan, pconnell, pitrou, pstch, rhettinger, santoso.wijaya, serhiy.storchaka, techtonik, terry.reedy, vstinner
Date 2017-01-31.13:33:13
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1485869594.0.0.567361563353.issue11549@psf.upfronthosting.co.za>
In-reply-to
Content
I would like to point out that the changes in `ast.literal_eval` may have some security risk for code that do not expect this function to return an object with user-controlled length (for example, with `2**32*'X'`). AFAIK, this is not possible with the current version of `literal_eval`.

At least [this library](https://pypi.python.org/pypi/serpent) would have a serious risk of remote DoS :

> Because it only serializes literals and recreates the objects using ast.literal_eval(), the serialized data is safe to transport to other machines (over the network for instance) and de-serialize it there.

Sorry for the noise if this is a useless/incorrect consideration.
History
Date User Action Args
2017-01-31 13:33:14pstchsetrecipients: + pstch, brett.cannon, georg.brandl, rhettinger, terry.reedy, gregory.p.smith, mark.dickinson, ncoghlan, pitrou, vstinner, techtonik, nadeem.vawda, benjamin.peterson, alex, Trundle, inada.naoki, dmalcolm, meador.inge, daniel.urban, Jeremy.Hylton, santoso.wijaya, eltoder, eric.snow, jcon, berker.peksag, serhiy.storchaka, pconnell, isoschiz
2017-01-31 13:33:14pstchsetmessageid: <1485869594.0.0.567361563353.issue11549@psf.upfronthosting.co.za>
2017-01-31 13:33:13pstchlinkissue11549 messages
2017-01-31 13:33:13pstchcreate