Quoting Greg Copeland :
> I take it a python solution without a sandbox will never be an option
> even if downloading of python scripts is excluded? Any particular reason
> to completely exclude the development of python AIs regardless of
> sandbox status?
It absolutely would be an option.
If so
On Tue, 2009-02-24 at 21:54 +0100, allefant wrote:
> Yes, any possible future AI or scripting additions should be discussed
> on the forum of course. Just was trying to clarify why I think the
> PythonAI failed - just generally blaming "Python" would be a bit
> simple-minded and not help prevent
On Tue, Feb 24, 2009 at 7:13 PM, Patrick Parker wrote:
> I'd like to point out that security issues aren't the only problem for our
> Python AI's.
> There's also stands the unresolved issue with redistribution of msvcr71.dll
> on Windows.
>
True, forgot about this, so besides the security issue a
На Tue, 24 Feb 2009 13:13:39 -0500
Patrick Parker wrote:
> I'd like to point out that security issues aren't the only problem for our
> Python AI's.
> There's also stands the unresolved issue with redistribution of msvcr71.dll
> on Windows.
>
> The GNU General Public Liscence (Wesnoth's end user
e such debates have already existed
>for some time now:
>
>[4]http://www.wesnoth.org/forum/viewtopic.php?f=2&t=19082
>
>--
>Sapient
>
>-------------------
>
>From: [5]gtcopel...@gmail.com
>
1:03:21 -0600
Subject: Re: [Wesnoth-dev] possible security problems (eg with current
python implementation)
Perhaps we should stand this on its head and look at it another way. We're
trying to knee-cap python because of a potential attack vector. If we remove
the potential attac
On Tue, 2009-02-24 at 16:52 +0100, allefant wrote:
> On Mon, Feb 23, 2009 at 10:50 PM, wrote:
> >
> > My point is that there has been a call out for a long time -- for
> > years -- that anyone wanting to make a nice API to Python for AI
> > purposes and then to write a nice AI can. If this API d
On Tue, 2009-02-24 at 16:52 +0100, allefant wrote:
> I agree, It doesn't bode well for Python as a language to use for game
> scripting. But in this case, it just means the missing sandboxing
> makes it the wrong choice of tool in the first place. Python would be
> an ideal language to re-write t
On Mon, Feb 23, 2009 at 10:50 PM, wrote:
>
> My point is that there has been a call out for a long time -- for
> years -- that anyone wanting to make a nice API to Python for AI
> purposes and then to write a nice AI can. If this API doesn't sandbox
> Python, that's fine, we just wouldn't allow e
Quoting Daniel Franke :
> d...@whitevine.net writes:
>
>> If we really can't develop a decent C++/Python API and then develop a
>> decent AI in Python, I don't think it bodes well for those who want to
>> convert more and more of Wesnoth into Python.
>>
>> I mean, this is a perfect test project to
d...@whitevine.net writes:
> If we really can't develop a decent C++/Python API and then develop a
> decent AI in Python, I don't think it bodes well for those who want to
> convert more and more of Wesnoth into Python.
>
> I mean, this is a perfect test project to show how well Python can
>
Quoting allefant :
> Also, the real reason to use
> scripting is not to write new AIs from scratch, but to augment the
> existing AI
If we really can't develop a decent C++/Python API and then develop a
decent AI in Python, I don't think it bodes well for those who want to
convert more and mor
On Mon, 2009-02-23 at 18:54 +0100, allefant wrote:
> We had Python support for years without safe.py or any restrictions at
> all. So this can't have been the problem.
It may not have been the original problem. It is a significant problem
now. I've spoken with and exchanged many forum posts, IR
On Mon, Feb 23, 2009 at 03:49:52PM +0100, David Philippi wrote:
> Am Montag 23 Februar 2009 schrieb Greg Copeland:
> > I personally would prefer for users be forced to police their own
> > security. In doing so we could offer a dual environment. One where
>
> Considering the usual level of securit
On Sun, Feb 22, 2009 at 07:25:46PM -0800, Daniel Franke wrote:
> Nils Kneuper writes:
>
> > 1) Limit PythonAI usage to stuff only available in the data/ main tree,
> > nothing
> > from userdata.
> > 2) Completely deactivate Python for the 1.6 series. This means not even
> > allowing
> > it to b
On Mon, Feb 23, 2009 at 3:40 PM, Greg Copeland wrote:
>
> I'm very pro-python. I'm the author of what was the start of the wail
> module. Having tried to work within the confines of the existing
> infrastructure, I do not see Python as a viable scripting option. Safe.py is
> nothing but a headache
На Mon, 23 Feb 2009 16:27:38 +0100
Nils Kneuper wrote:
> In general our addon server for 1.4.x will not send anything python related
> that
> the game can make use of, but users can of course copy the stuff in from
> "anywhere in the depths of the net", so the only way to be secure is to
> deact
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Okay, in revision 33040 dfranke removed PythonAI support from Wesnoth. That is
in 1.6 *no* Python is available ingame at all. Python is still used for several
"external" tools (like eg wmllint and many others), but the game itself will not
rely on Pyth
On Sun, 2009-02-22 at 19:25 -0800, Daniel Franke wrote:
> Nils Kneuper writes:
>
> > 1) Limit PythonAI usage to stuff only available in the data/ main tree,
> > nothing
> > from userdata.
> > 2) Completely deactivate Python for the 1.6 series. This means not even
> > allowing
> > it to be comp
> Considering the usual level of security expertise for an average user, this is
> no option at all to me. Better use a language designed for such usage.
>
Agreed, we are a video game, our users can have any age over 8, we
can't expect them to do informed security decision.
> Bye,
> David
>
> ___
Am Montag 23 Februar 2009 schrieb Greg Copeland:
> I personally would prefer for users be forced to police their own
> security. In doing so we could offer a dual environment. One where
Considering the usual level of security expertise for an average user, this is
no option at all to me. Better u
Nils Kneuper writes:
> 1) Limit PythonAI usage to stuff only available in the data/ main tree,
> nothing
> from userdata.
> 2) Completely deactivate Python for the 1.6 series. This means not even
> allowing
> it to be compiled into the binary via the build systems.
It was I who proposed option
On Sun, 2009-02-22 at 18:08 +0100, Nils Kneuper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Hi everybody!
> dfranke lately spotted several possible security issues in our code. That is
> of
> those findings, so far two led us to the conclusion "serious enough for
> official
> re
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
On Sun, Feb 22, 2009 at 6:08 PM, Nils Kneuper 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) se
On Sun, Feb 22, 2009 at 06:08:15PM +0100, Nils Kneuper wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> 1) Limit PythonAI usage to stuff only available in the data/ main tree,
> nothing
> from userdata.
> 2) Completely deactivate Python for the 1.6 series. This means not even
> allow
26 matches
Mail list logo
