Here we capture the most significant risks to the success of the project, along with proposed ways to mitigate those risks.

• Risk: There is an existing PythonMethods prototype that is in fairly wide use. There will likely be backward compatibility issues as a part of this project that would break many existing sites/products.

  Proposed mitigation: We should probably try to package the new builtin PythonMethods in a way that allows people to continue to use the older version without breaking until they can convert their old objects. The old add-on product should be deprecated, and we should give users a guide to upgrading (and possibly tools, if that makes any sense).

• Risk: The current prototype of PythonMethods has an "unrestricted mode" that we cannot include in the core.

  Proposed mitigation: We'll need to note this as an upgrade issue for those people who may be depending on this (highly unsafe) behavior.

  PJE

  another possibility might be code signing. I.e., provide the ability for digitally signed code to execute, with the signature having to include the _p_oid in some way, preventing replay attacks. This idea is probably outside the scope of this project proposal, but it might be worth thinking about for the future.

• Risk: DTML can overconsume memory and CPU time, but has various restrictions which make it hard to do so. Python code is more prone to overconsumption of resources. In particular, infinite (or arbitrarily long) loops are much easier to create, either deliberately or accidentally.

  Proposed mitigation: LoopLimits tries to prevent inadvertent runaway looping, but it would be **really* nice if we could impose hard CPU and memory limits on user code. Ideally, user code would run in a secondary interpreter with built-in security and quota support.