Message242006
| Author |
ncoghlan |
| Recipients |
brett.cannon, larry, ncoghlan, pdmccormick, serhiy.storchaka, yselivanov, zach.ware |
| Date |
2015年04月25日.08:02:33 |
| SpamBayes Score |
-1.0 |
| Marked as misclassified |
Yes |
| Message-id |
<1429948953.75.0.431828168547.issue23967@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
Right, Larry and I had a fairly long discussion about this idea at the sprints, and I was satisfied that all the cases where he's proposing to use this are safe: in order to exploit them you need to be able to set __text_signature__ on arbitrary objects, and if an attacker can do that, you've already lost control of the process.
However, a natural future extension is to expose this as a public alternative constructor for Signature objects, and for that, the fact that it ultimately calls eval() under the hood presents more of a security risk. The "trusted=False" default on _signature_fromstr allows the function to be used safely on untrusted data, while allowing additional flexibility when you *do* trust the data you're evaluating. |
|