just a quick note : the bugs reported are "private" i.e only registered devs can view them, however, this mailing list is not. So please avoid discussing the vulnerabilites themselves here
this might be obvious to everybody, but it's better repeated OK, I would also vote for 2, my main argument is that there is still a known attack vector which can lead to serious problems, even if it si mitigated. Moreover, pythonAI has been around since 1.2 and no serious attempt to use it was produced. I don't think this feature will be used in the future anyway. If it was meant to happen, it would already have happened Boucman On Sun, Feb 22, 2009 at 6:28 PM, allefant <allef...@gmail.com> wrote: > On Sun, Feb 22, 2009 at 6:08 PM, Nils Kneuper <crazy-ivano...@gmx.net> wrote: >> >> Long mail cut short: >> What about 1.6? Should we got for 1) or for 2)? Or does anyone of you have >> even >> a better idea what we should do? >> Personally I vote for 2) since PythonAI is not really used and it would >> reduce >> the (possible) security problems with it to zero (not to speak about the >> positive impact on packagers with less dependencies). >> > > I'd also say, go for 2. The current PythonAI implementation had two > big design problems from the start. > > First, it uses the C-Python API which is very low-level and makes it > hard to maintain. This means, it's not a big loss removing this > version - if Python scripting is wanted, better start fresh with > Boost::Python or similar. > > Second, no thought was spent on security when it was first > implemented. Historically, when I was taking over maintenance of it > for some time, I first added code to the campaign server to disallow > Python scripts until someone would verify it (this is essentially the > security model used by most other projects allowing Python scripting). > Later someone provided us with the safe.py wrapper - but the idea was > flawed from the beginning. For one, it removed a lot of the Python > language features, so scripts aren't really Python any longer. And it > adds a lot more maintenance burden again, apparently neither the > "queue" nor the "threading" module were safe to whitelist - the > original author of safe.py likely would have known that, but I did > not. Casically, Python does not support sandboxing - but I think it's > a feature we much should require for Wesnoth scripting. > > _______________________________________________ > Wesnoth-dev mailing list > Wesnoth-dev@gna.org > https://mail.gna.org/listinfo/wesnoth-dev > _______________________________________________ Wesnoth-dev mailing list Wesnoth-dev@gna.org https://mail.gna.org/listinfo/wesnoth-dev
