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 Devin Jeanpierre
Recipients Devin Jeanpierre, alex, brett.cannon, christian.heimes, gregory.p.smith, terry.reedy
Date 2017-05-02.23:04:26
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Aha, I found an existing issue!

For adding to oss-fuzz, is there a contact email we can use that is connected to a google account? I am tempted to just put gregory.p.smith on there if not. :)

I can volunteer to fuzz some interesting subset of the stdlib. The list I've come up with (by counting uses in my code) is:

the XML parser (which seems to be written in C)
struct (unpack)
the various builtins that parse strings (like int())
datetime's parsing

I'd also suggest the ast module, since people do use ast.literal_eval on untrusted strings, but I probably won't do that one myself.

I wrote a fuzz test for json via upstream simplejson, but the bug on github is getting stale:

Should I add it to CPython instead?

> We should investigate creating fuzz targets for the Python re module (_sre.c) at a minimum.

If we prioritize based on security risk, I'd argue that this is lower priority than things like json's speedup extension module, because people should generally not pass untrusted strings to the re module: it's very easy to DOS a service with regexes unless you're using RE2 or similar -- which is fuzzed.  In contrast, json is supposed to accept untrusted input and people do that very often.

(OTOH, I would be willing to bet that fuzzing re will yield more bugs than fuzzing json.)
Date User Action Args
2017-05-02 23:04:26Devin Jeanpierresetrecipients: + Devin Jeanpierre, brett.cannon, terry.reedy, gregory.p.smith, christian.heimes, alex
2017-05-02 23:04:26Devin Jeanpierresetmessageid: <>
2017-05-02 23:04:26Devin Jeanpierrelinkissue29505 messages
2017-05-02 23:04:26Devin Jeanpierrecreate