This is really bad news, guys...
% package require XOTcl 1.6.2 % namespace import xotcl::* % Class Foo ::Foo % Foo instproc init {a} {puts $a} % set a "-test" -test % Foo new $a ::xotcl::__#0: unable to dispatch method 'test' during '::xotcl::__#0 test'
In other words: it is totally impossible to pass in a value beginning with "-" to an XOTcl constructor using the normal instantiation methods. This means absolutely anything where you don't know what is going to be passed beforehand is at a huge risk, as obviously any text can thus call random methods. That is without doing the whole process manually (ie. alloc, init). And you'd have to do it almost always, to be safe.
Even if the usual Tcl "--" style was used, I still think that would not be enough, as practically speaking you'd have to use that every single time, making the code horribly ugly. It's just about acceptable for [switch], but not for a constructor, where people fully expect to be able to pass in any variable...
Please tell me I'm dreaming (it's almost 4am here)
Hi! I found a work around according to xotcl documentation. Foo new [list -init $a] I had also problems with -_values by parameters. I often write class methods to create and init instances. (Smalltalk style). Something like: Foo proc createInstace {a} { set a [Foo new] $a set arg1 $a $a initme return $a }
Artur
Kristoffer Lawson setok@scred.com hat am 4. August 2010 um 02:42 geschrieben:
This is really bad news, guys...
% package require XOTcl 1.6.2 % namespace import xotcl::* % Class Foo ::Foo % Foo instproc init {a} {puts $a} % set a "-test" -test % Foo new $a ::xotcl::__#0: unable to dispatch method 'test' during '::xotcl::__#0 test'
In other words: it is totally impossible to pass in a value beginning with "-" to an XOTcl constructor using the normal instantiation methods. This means absolutely anything where you don't know what is going to be passed beforehand is at a huge risk, as obviously any text can thus call random methods. That is without doing the whole process manually (ie. alloc, init). And you'd have to do it almost always, to be safe.
Even if the usual Tcl "--" style was used, I still think that would not be enough, as practically speaking you'd have to use that every single time, making the code horribly ugly. It's just about acceptable for [switch], but not for a constructor, where people fully expect to be able to pass in any variable...
Please tell me I'm dreaming (it's almost 4am here)
-- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
On 4 Aug 2010, at 10:08, mail@xdobry.de wrote:
Hi!
I found a work around according to xotcl documentation.
Foo new [list -init $a]
Thanks yes, as tired as I was last night, I didn't come up with that. The thing is, that basically has to be done all the time if you are passing in variables. Obviously any time you pass user-generated string, but also in other cases as well when you can't be 100% sure of the content (and often you can't). I probably have hundreds of places where this can cause a bug, at best, and a security hole, at worst.
Using [list -init <vars>] all the time does not, to me, sound like elegant programming. I use the dash feature much more infrequently than just plain instantiation. Besides, you are at risk even with the dash feature, if you pass it an argument...
I'm not exactly sure even how I would solve this for XOTcl. Any special argument syntax is always going to be at risk. As mentioned, even arguments to the dash values are risky. In that respect I would consider dropping the whole feature. It's that risky.
Dear Kristoffer and all.
yes, this is a part, where xotcl was criticized for in the past - not without reason. The problem is a tribute to invocations to methods with a variable number of arguments in the dash notation (calling methods with zero to n arguments) without knowing the length of the argument list (which is in the general case not possible in Tcl due to args). For me it is sometimes surprising, how well it works even for large projects, with several thousand lines of code and many developers involved. The XOTcl serializer uses the dash notation as well, but analyses the arguments and adds the lists as needed.
Anyhow, the next incarnation of XOTcl, on which we are hard working right now, has this feature dropped, and provides a much more orthogonal parameterization for objects and methods. As the new framework supports multiple object systems in one interpreter, one can use classical XOTcl and the new object system in parallel.
best regards -gustaf neumann
Am 04.08.10 11:07, schrieb Kristoffer Lawson:
On 4 Aug 2010, at 10:08, mail@xdobry.de wrote:
Foo new [list -init $a]
Thanks yes, as tired as I was last night, I didn't come up with that. The thing is, that basically has to be done all the time if you are passing in variables. Obviously any time you pass user-generated string, but also in other cases as well when you can't be 100% sure of the content (and often you can't). I probably have hundreds of places where this can cause a bug, at best, and a security hole, at worst.
Using [list -init<vars>] all the time does not, to me, sound like elegant programming. I use the dash feature much more infrequently than just plain instantiation. Besides, you are at risk even with the dash feature, if you pass it an argument...
I'm not exactly sure even how I would solve this for XOTcl. Any special argument syntax is always going to be at risk. As mentioned, even arguments to the dash values are risky. In that respect I would consider dropping the whole feature. It's that risky.
On 4 Aug 2010, at 12:37, Gustaf Neumann wrote:
without knowing the length of the argument list (which is in the general case not possible in Tcl due to args). For me it is sometimes surprising, how well it works even for large projects, with several thousand lines of code and many developers involved. The XOTcl serializer uses the dash notation as well, but analyses the arguments and adds the lists as needed.
Yes, this is the first time I came across this, and it took a while to debug :-) However I'm almost certain a lot of code I have stored around is susceptible to the same thing. That's the danger with this: it's very easy to get by by just passing in arguments in the normal way, and then end up with a severe security hole. It's very easy to miss, as it's quite natural for a coder to pass in arguments directly to constructors.
Anyhow, the next incarnation of XOTcl, on which we are hard working right now, has this feature dropped, and provides a much more orthogonal parameterization for objects and methods. As the new framework supports multiple object systems in one interpreter, one can use classical XOTcl and the new object system in parallel.
I think dropping it is a good decision. It'll be interesting to see what the next XOTcl is like.
How much complexity will the new version be adding? The beauty with XOTcl, especially the earlier versions, was that despite the power of it, it was quite simple (unlike C++). Much like Tcl itself: power, but simplicity. I would be concerned if that gets lost along the way.
Am 04.08.10 14:14, schrieb Kristoffer Lawson:
I think dropping it is a good decision. It'll be interesting to see what the next XOTcl is like.
How much complexity will the new version be adding? The beauty with XOTcl, especially the earlier versions, was that despite the power of it, it was quite simple (unlike C++). Much like Tcl itself: power, but simplicity. I would be concerned if that gets lost along the way.
the new object system as a much smaller interface (half the number of predefined methods) and the whole system is more orthogonal.
See e.g. the paper at and slides from the last tcl tk conference. http://nm.wu-wien.ac.at/research/publications/b802.pdf http://nm.wu-wien.ac.at/research/publications/b806.pdf
you can follow the development via git
git clone git://alice.wu-wien.ac.at/xotcl 2.0.0-develop cd 2.0.0-develop git branch 2.0.0-develop origin/2.0.0-develop git checkout 2.0.0-develop
all the best -gustaf neumann
Isn't it fair to say that by design, any dynamic language has such possible traps and pitfalls... (although this one is especially awkward). You don't need to try very hard to make TCL fall over in all sorts of ways like this.
The question I always ask my teams when something like this comes up is - Why didn't the unit tests catch it - What 'stock' unit test will we add in future to catch it
It's very easy to miss, as it's quite natural for a coder to pass in arguments directly to constructors.
Its quite hard to miss if you TDD it...
Over a fairly short period of time you soon have a nice set of unit test classes that always try an throw up these sorts of problems. Probably about half a dozen small tests that pump in 'iffy' stuff to a method covers it.. and because of the beauty of typeless (or stringly typed) languages than can be readily used without modification
Anyway, just my thoughts.
Regards Simon
On 4 Aug 2010, at 13:14, Kristoffer Lawson wrote:
On 4 Aug 2010, at 12:37, Gustaf Neumann wrote:
without knowing the length of the argument list (which is in the general case not possible in Tcl due to args). For me it is sometimes surprising, how well it works even for large projects, with several thousand lines of code and many developers involved. The XOTcl serializer uses the dash notation as well, but analyses the arguments and adds the lists as needed.
Yes, this is the first time I came across this, and it took a while to debug :-) However I'm almost certain a lot of code I have stored around is susceptible to the same thing. That's the danger with this: it's very easy to get by by just passing in arguments in the normal way, and then end up with a severe security hole. It's very easy to miss, as it's quite natural for a coder to pass in arguments directly to constructors.
Anyhow, the next incarnation of XOTcl, on which we are hard working right now, has this feature dropped, and provides a much more orthogonal parameterization for objects and methods. As the new framework supports multiple object systems in one interpreter, one can use classical XOTcl and the new object system in parallel.
I think dropping it is a good decision. It'll be interesting to see what the next XOTcl is like.
How much complexity will the new version be adding? The beauty with XOTcl, especially the earlier versions, was that despite the power of it, it was quite simple (unlike C++). Much like Tcl itself: power, but simplicity. I would be concerned if that gets lost along the way.
-- Kristoffer Lawson, Co-Founder, Scred // http://www.scred.com/
Xotcl mailing list Xotcl@alice.wu-wien.ac.at http://alice.wu-wien.ac.at/mailman/listinfo/xotcl
-
Gustaf Neumann -
Gustaf Neumann -
Kristoffer Lawson -
mail＠xdobry.de -
SImon Millward