It is possible to craft a MO file with Plural-Forms taking arbitrary amounts of CPU and memory to evaluate. A test case is attached.I realize that opening unstrusted MO files is a rather unusual use case, but the module already contains some code to protect againt malicious Plural-Forms, so I thought you might want to fix this problem as well.

Thanks,can you please provide the PO file, too? Or did you construct the MO file manually?

Ah, I see what you are doing. Nice catch!Plural-Forms: nplurals=0; plural=42**42**42;The plural form gets parsed by gettext.c2py() and eventually turned into a lambda that executes int(42**42**42). Perhaps a custom AST visitor could be used to filter out dangerous ops and limit the amount of ops to a sane amount?

Why do we have "support" for untrusted MO files?

I would rather ask: why do we eval() MO files?

We don't eval() the whole MO file. It's just the pluralization formula,http://www.gnu.org/software/gettext/manual/gettext.html#index-nplurals_0040r_007b_002c-in-a-PO-file-header_007d-1093The patch uses ast.NodeVisitor to look for dangerous code.

Making token filtering more thorough may be simpler that going through AST.I think Python should accept all the operators that GNU gettext accepts:http://git.savannah.gnu.org/cgit/gettext.git/tree/gettext-runtime/intl/plural.y?id=v0.18.2.1#n132

Thanks for the link plural.y! I was looking for a C file, not a YACC file.The AST approach has advantages over tokenizing. The tokenizer returns just symbols but the AST has also context information. It makes it much easier to distinguish between unary - and binary -. Gettext supports substraction but doesn't allow negative numbers.Python's gettext is not as strict as GNU gettext. For 3.4 I like to forbid oct and hex numbers, too.

The DoS as well as other flaws is fixed inissue28563 by implementing a complete parser for GNU gettext plural form expressions.