perlplusplugin-developers Mailing List for PerlPlusPlugin
Status: Beta
Brought to you by:
fholtry
Menu
▾
▴
perlplusplugin-developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
(14) |
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(8) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Steve L. <so...@Le...> - 2005-07-14 13:15:11
|
On Jul 14, 2005, at 8:53 AM, Dmitry Karasik wrote: > > Steve> You could at least try to be diplomatic. Many people have > spent > Steve> years of their lives working on Perl/Tk, and all you can do > is slap > Steve> them in the face! > > No doubt they have. I'm sorry for stepping on egos, I admit that > Perl-Tk No ego stepped on here, so no apology required ;) > might be the most holy cow in the circus, but it is still visually > old, True, it either looks Motiff-ish or Window-ish. TCL/TK has more variety here, so they may take exception with you! > badly portable, excruciatingly hard to extend, has quite a non-perl > syntax and messed up namespace, and IMO is basically a huge hack. However, none of the above do I agree with. > > The reason why Perl-Tk pops up first when people look for a perl GUI > toolkit is a pure coincidence. Again, I apologize for sounding rude, > I didn't mean to be rude but rather bitter. I can understand. When pTk first came out it was still modern. And to be able to write a perl GUI - easily - was a wonder. BUu, although I'm a devote Unix hacker, I don't do pTk much anymore. I still marvel at the OS on the PowerMacs that I use daily, and marvel at the MAC OS X GUI, Aqua. I'm not bitter, just sad that pTk can't look that stunning ;) Steve > > /dk > |
|
From: Dmitry K. <dm...@ka...> - 2005-07-14 12:54:09
|
Steve> You could at least try to be diplomatic. Many people have spent Steve> years of their lives working on Perl/Tk, and all you can do is sl= ap Steve> them in the face! No doubt they have. I'm sorry for stepping on egos, I admit that Perl-Tk might be the most holy cow in the circus, but it is still visually old,=20 badly portable, excruciatingly hard to extend, has quite a non-perl=20 syntax and messed up namespace, and IMO is basically a huge hack. The reason why Perl-Tk pops up first when people look for a perl GUI toolkit is a pure coincidence. Again, I apologize for sounding rude,=20 I didn't mean to be rude but rather bitter. /dk |
|
From: Steve L. <so...@Le...> - 2005-07-13 12:22:59
|
On Jul 13, 2005, at 7:25 AM, Dmitry Karasik wrote: > Hi Uong,! > > Uong,> on > > Uong,> Firefox. I see there are Firefox extensions MozPHP and > MozPython. > Uong,> I am volunteer to be a validation engineer for PerlPlus on > Firefox > Uong,> or if you have MozPerl !!! > > I'd be curious what would you choose for GUI, because Perl-Tk sucks You could at least try to be diplomatic. Many people have spent years of their lives working on Perl/Tk, and all you can do is slap them in the face! > big time, while other perl GUI libraries are unpopular. > > /dk > > > > Uong,> -----Original Message----- From: Steve Lidie > Uong,> [mailto:so...@le...]=20 Sent: Monday, July 11, 2005 > 5:24 AM To: > Uong,> Uong, Hoang D Cc: perlplusplugin- > dev...@li... > Uong,> Subject: Re: [Perlplusplugin-developers] Hello ! > > > Uong,> On Jul 11, 2005, at 12:44 AM, Uong, Hoang D wrote: > > >>> Hi, I just learned about the existence of PerlPlusPlugin from the >>> =20 >>> book Mastering PerlTk. If this mailing list is still active ? - >>> I am >>> very interested to =20 use the plugin in Firefox. If any one has >>> any >>> idea, please let me know. >>> > > Uong,> It's only been tested with Netscape AFAIK. What would be > Uong,> interesting =20 is to see how the new TCL/Tk plugin works, > maybe it > Uong,> can be adapted =20 for Perl. No time here, however ... > > > >>> Thanks so much, >>> >>> Hoang >>> >>> >>> >>> > > > > Uong,> ------------------------------------------------------- > This SF.Net > Uong,> email is sponsored by the 'Do More With Dual!' webinar > happening > Uong,> July 14 at 8am PDT/11am EDT. We invite you to explore the > latest in > Uong,> dual core and dual graphics technology at this free one > hour event > Uong,> hosted by HP, AMD, and NVIDIA. To register visit > Uong,> http://www.hp.com/go/dualwebinar > Uong,> _______________________________________________ > Uong,> Perlplusplugin-developers mailing list > Uong,> Per...@li... > Uong,> https://lists.sourceforge.net/lists/listinfo/perlplusplugin- > developers > > > -- > Sincerely, > Dmitry Karasik > > --- > catpipe Systems ApS > *BSD solutions, consulting, development > www.catpipe.net > +45 7021 0050 > > > ------------------------------------------------------- > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Perlplusplugin-developers mailing list > Per...@li... > https://lists.sourceforge.net/lists/listinfo/perlplusplugin-developers > |
|
From: Dmitry K. <dm...@ka...> - 2005-07-13 11:25:25
|
Hi Uong,! Uong,> on Uong,> Firefox. I see there are Firefox extensions MozPHP and MozPython. Uong,> I am volunteer to be a validation engineer for PerlPlus on Firefo= x Uong,> or if you have MozPerl !!! I'd be curious what would you choose for GUI, because Perl-Tk sucks big time, while other perl GUI libraries are unpopular. /dk Uong,> -----Original Message----- From: Steve Lidie Uong,> [mailto:so...@le...]=3D20 Sent: Monday, July 11, 2005 5:24 AM= To: Uong,> Uong, Hoang D Cc: per...@li... Uong,> Subject: Re: [Perlplusplugin-developers] Hello ! Uong,> On Jul 11, 2005, at 12:44 AM, Uong, Hoang D wrote: >> Hi, I just learned about the existence of PerlPlusPlugin from the =3D= 20 >> book Mastering PerlTk. If this mailing list is still active ? - I am >> very interested to =3D20 use the plugin in Firefox. If any one has a= ny >> idea, please let me know. Uong,> It's only been tested with Netscape AFAIK. What would be Uong,> interesting =3D20 is to see how the new TCL/Tk plugin works, mayb= e it Uong,> can be adapted =3D20 for Perl. No time here, however ... >> Thanks so much, >>=20 >> Hoang >>=20 >>=20 >>=20 Uong,> ------------------------------------------------------- This SF.N= et Uong,> email is sponsored by the 'Do More With Dual!' webinar happening Uong,> July 14 at 8am PDT/11am EDT. We invite you to explore the latest = in Uong,> dual core and dual graphics technology at this free one hour even= t Uong,> hosted by HP, AMD, and NVIDIA. To register visit Uong,> http://www.hp.com/go/dualwebinar Uong,> _______________________________________________ Uong,> Perlplusplugin-developers mailing list Uong,> Per...@li... Uong,> https://lists.sourceforge.net/lists/listinfo/perlplusplugin-devel= opers --=20 Sincerely, Dmitry Karasik --- catpipe Systems ApS *BSD solutions, consulting, development www.catpipe.net +45 7021 0050 =20 |
|
From: Uong, H. D <hoa...@in...> - 2005-07-11 19:20:27
|
Hi, Thanks so much for the info. It would be nice to see PerlPlus on Firefox. I see there are Firefox extensions MozPHP and MozPython. I am volunteer to be a validation engineer for PerlPlus on Firefox or if you have MozPerl !!! Thanks, Hoang -----Original Message----- From: Steve Lidie [mailto:so...@le...]=20 Sent: Monday, July 11, 2005 5:24 AM To: Uong, Hoang D Cc: per...@li... Subject: Re: [Perlplusplugin-developers] Hello ! On Jul 11, 2005, at 12:44 AM, Uong, Hoang D wrote: > Hi, > I just learned about the existence of PerlPlusPlugin from the =20 > book Mastering PerlTk. > If this mailing list is still active ? - I am very interested to =20 > use the plugin in Firefox. > If any one has any idea, please let me know. It's only been tested with Netscape AFAIK. What would be interesting =20 is to see how the new TCL/Tk plugin works, maybe it can be adapted =20 for Perl. No time here, however ... > > Thanks so much, > > Hoang > > > |
|
From: Steve L. <so...@Le...> - 2005-07-11 12:24:21
|
On Jul 11, 2005, at 12:44 AM, Uong, Hoang D wrote: > Hi, > I just learned about the existence of PerlPlusPlugin from the > book Mastering PerlTk. > If this mailing list is still active ? - I am very interested to > use the plugin in Firefox. > If any one has any idea, please let me know. It's only been tested with Netscape AFAIK. What would be interesting is to see how the new TCL/Tk plugin works, maybe it can be adapted for Perl. No time here, however ... > > Thanks so much, > > Hoang > > > |
|
From: Uong, H. D <hoa...@in...> - 2005-07-11 04:44:16
|
Hi,
I just learned about the existence of PerlPlusPlugin from the book
Mastering PerlTk.
If this mailing list is still active ? - I am very interested to use the
plugin in Firefox.
If any one has any idea, please let me know.
=20
Thanks so much,
=20
Hoang
=20
=20
=20
|
|
From: Dmitry K. <dm...@ka...> - 2004-01-19 12:43:24
|
Hi Henrik! On 19 Jan 04 at 11:52, "Henrik" (Henrik Edlund) wrote: DK> It won't. Henrik> If it works with NS4 it should. Alas, it only does so on os2/win32. -- Sincerely, Dmitry --- www.karasik.eu.org --- He who dies with most the toys wins |
|
From: Henrik E. <he...@ed...> - 2004-01-19 10:52:41
|
On Mon, 19 Jan 2004, Dmitry Karasik wrote: DK> It won't. If it works with NS4 it should. |
|
From: Dmitry K. <dm...@ka...> - 2004-01-19 10:32:08
|
Hi Henrik! On 19 Jan 04 at 03:44, "Henrik" (Henrik Edlund) wrote: Henrik> On Sun, 18 Jan 2004, Dmitry Karasik wrote: DK> Anyway, if you would like to experiment with the code you're welcome. Henrik> I might try to compile it on Solaris and see if it works with Henrik> Mozilla. It won't. -- Sincerely, Dmitry --- www.karasik.eu.org --- He who dies with most the toys wins |
|
From: Henrik E. <he...@ed...> - 2004-01-19 02:45:43
|
On Sun, 18 Jan 2004, Dmitry Karasik wrote: DK> Anyway, if you would like to experiment with the code you're welcome. I might try to compile it on Solaris and see if it works with Mozilla. henrik |
|
From: Dmitry K. <dm...@ka...> - 2004-01-18 15:20:13
|
Hi Henrik! On 17 Jan 04 at 04:07, "Henrik" (Henrik Edlund) wrote: Henrik> So the project is basically dead and there will be no new Henrik> development? No development - yes, there's no development. Dead - no, it's working very well on win32 and os2 and IMHO doesn't need special attention to be developed further primarily because it never gained wide recognition as it is. When I first met the project I expected perl to match java in the plugin area, and combined perl graphic toolkit Prima with the plugin, which worked just fine and allowed to run perl graphic things exactly in same fashion as java does. Now, java browser plugin itself is marginal, and I hardly expect perl browser plugin to reach any significant popularity. Anyway, if you would like to experiment with the code you're welcome. -- Sincerely, Dmitry --- www.karasik.eu.org --- He who dies with most the toys wins |
|
From: Henrik E. <he...@ed...> - 2004-01-17 03:07:57
|
On Sat, 17 Jan 2004, Dmitry Karasik wrote: DK> Long time since I've ever seen any. So the project is basically dead and there will be no new development? |
|
From: Dmitry K. <dm...@ka...> - 2004-01-16 23:30:02
|
Hi Henrik! On 15 Jan 04 at 22:35, "Henrik" (Henrik Edlund) wrote: Henrik> Is there still any activity in this project? Henrik Long time since I've ever seen any. -- Sincerely, Dmitry --- www.karasik.eu.org --- He who dies with most the toys wins |
|
From: Henrik E. <he...@ed...> - 2004-01-15 21:35:25
|
Is there still any activity in this project? Henrik |
|
From: Frank H. <fh...@lu...> - 2000-09-20 15:05:06
|
On 20 Sep 2000, Dmitry Karasik wrote: > >Hi Frank! > > Frank> This code successfully preserves the Perl/Tk windows most of the > Frank> time, but not quite all the time. I attribute this to the fact > Frank> that it sometimes loses the race with the X-server, but I don't > Frank> know a way yet to prove that's what happens. > >I looked at the script, but I can't test it right now - I'm testing >now the Plugin <-> Prima ipc, and I'm currently under win32. Are you dual-booting? There's an incredible virtual machine called Vmware (http://www.vmware.com) that let's you run two (or more) OS's simultaneously on X86 machines. Simple keystrokes let you move back and forth between them. I use it daily on my desktop at work because I have to work in Unix/Linux and Winnt environments. >As you say, it is not a reliable method to catch events - my idea is, that >using the module I'm writing now, it will be possible to get notification >directly from the plugin. That should be working in win32, but I can't say >anything about X until I test it. The solution I'm trying to make is that >the Plugin ( or Netscape) would send a reliable signal to a listening perl >program. > But anyway, I have to get the thick X book, because the whole thing looks very >strange - the DestroyNotify comes bottom-up, that's right - but I believed >that under any circumstances a child could access it's parent. With X, you have a minimum of two independant processes involved all the time. The X server is responsible for creating and managing the windows and your application has to request those services from it. With the current plugin design you add the Perl interpreter as a third independant process. Window resources are sort of jointly owned by the X server and whatever process requested their creation. They can prevent other processes from accessing the resources, including the events. Even though the owning process may allow for instance a third process to reparent windows into it's heirarchy, that doesn't necessarily imply that the third process has accesss to any other resources. I established mostly by trial and error which events the Perl process could mask on which windows. >I have to look at the manual, or maybe if you have one, please find these Check http://www.x.org and http://www.rahul.net/kenton/xsites.framed.html. The kenton site has a huge amount of information on X , including an html version of the Xlib manual. I actually just discovered this site this morning because ftp://ftp.x.org, which used to have a lot of such stuff, is either down or dead. Kenton looks like a better choice anyway. >specifications also - because mine isn't full. > > PS. - From the other hand, if the X protocol guarantess that a parent is always >visible to a child, it is not a race then, but something else. This is an area where I'm a little fuzzy as to just how X works. According to the docs, the X server is supposed to wait for all processes that have masked an event to respond to it. Especially with the DestroyNotify event, this would seem to be critical so that the process could preserve any state it needed before the window was destroyed. My experience with the Plugin seems to indicate this isn't always what happens. What I don't know is how the X server determines that a process has trapped the event and responded to it. It could be that the process needs to explicitly signal the server; maybe Perl/Tk does that too soon. It could be too that the only process waited for is the owner/creator. I just don't know at the moment. >( an error in the manual :) > >-- >Sincerely, > Dmitry > >--- www.karasik.eu.org --- > >_______________________________________________ >Perlplusplugin-developers mailing list >Per...@li... >http://lists.sourceforge.net/mailman/listinfo/perlplusplugin-developers > -- ------------------------------------------------------------------------------- | Frank Holtry | "If you have the right attitude, interesting | | fh...@av... | problems will find you." | | | Eric S. Raymond | ------------------------------------------------------------------------------- |
|
From: Dmitry K. <dk...@pl...> - 2000-09-20 08:20:04
|
Hi Frank! Frank> This code successfully preserves the Perl/Tk windows most of the Frank> time, but not quite all the time. I attribute this to the fact Frank> that it sometimes loses the race with the X-server, but I don't Frank> know a way yet to prove that's what happens. I looked at the script, but I can't test it right now - I'm testing now the Plugin <-> Prima ipc, and I'm currently under win32. As you say, it is not a reliable method to catch events - my idea is, that using the module I'm writing now, it will be possible to get notification directly from the plugin. That should be working in win32, but I can't say anything about X until I test it. The solution I'm trying to make is that the Plugin ( or Netscape) would send a reliable signal to a listening perl program. But anyway, I have to get the thick X book, because the whole thing looks very strange - the DestroyNotify comes bottom-up, that's right - but I believed that under any circumstances a child could access it's parent. I have to look at the manual, or maybe if you have one, please find these specifications also - because mine isn't full. PS. - From the other hand, if the X protocol guarantess that a parent is always visible to a child, it is not a race then, but something else. ( an error in the manual :) -- Sincerely, Dmitry --- www.karasik.eu.org --- |
|
From: Frank H. <fh...@av...> - 2000-09-19 14:10:40
|
Dmitry, Here's the Perl program I was using to learn how X works and to experiment with preserving a window while Netscape resizes. The idea was to trap the ResizeRedirect and SubstructureNotify events before the destroy happened, reparent the window and it's descendants outside the Netscape heirarchy and then reparent them back into the heirarchy once Netscape had settled down from the resize. Note that I view trees of this sort as inverted, so the root node is at the top and the leaves are at the bottom. 'Up' means toward the root node and 'down' means toward the leaves. Yesterday, I indicated that events propagate up the tree, but I think that's incorrect. Most event notifications are propagated down the tree, so I set masks on windows a few levels above the embedded window. However, destroys happen from the bottom up, obviously. This code successfully preserves the Perl/Tk windows most of the time, but not quite all the time. I attribute this to the fact that it sometimes loses the race with the X-server, but I don't know a way yet to prove that's what happens. An alternative to this approach is to have the Perl program detect the destruction of it's children and reconstruct them. I haven't experimented with this yet. It might be tricky for windows displaying rapidly changing data -- scrolling text, for example -- since you'd want to restore to the exact place in the text where the destroy occurred. Maybe widgets could be designed to respond to X-events and preserve enough state to make such reconstructions easier. -- ------------------------------------------------------------------------------- | Frank Holtry | "If you have the right attitude, interesting | | fh...@av... | problems will find you." | | | Eric S. Raymond | ------------------------------------------------------------------------------- |
|
From: Dmitry K. <dk...@pl...> - 2000-09-16 15:01:07
|
Hi Frank! On 15 Sep 00 at 16:46, "Frank" (Frank Holtry) wrote: >> >> However, the subject of security itself is a tough one, so the real >> opsets and wrappers require thorough design. Frank> Do you think more needs to be done with opsets than what is Frank> currently in np_perl.h? And you say 'wrappers' as if more than one Frank> might be needed? The sequence of programs and modules involved are currently Prima-oriented, so to say. But I don't want to make the plugin working only with Prima - I want to keep it's current functionality, when non-gui scripts could be launched also. I have now only one wrapper - but it has 'nice GUI' and windows and all that stuff - but it requires Prima to be installed. Maybe the same thing will be written latter for Tk. The one I have written now, is rather toyish - since when subprogram fails, it analyzes the output and if it was sort of 'no package blabla found' it launches either CPAN or PPM gui setups with nice buttons and all that kind of stuff. But I'm afraid that if opcode-security scheme will be applied, I'll have to remove them... Frank> But if the Prima widgets are designed from the beginning to work Frank> with both a plugin and an external event loop, I think it would be Frank> a dynamite tool. I hope also! >> But, I read the plugin guide and it says that NPP_SetWindow is called ( >> in this case) with two different windows, so there's a moment when both >> old and new windows are alive? If it is so, then a blocking >> notification Frank> NPP_SetWindow( NPP instance, NPWindow * window) is what I have for Frank> the function, which only has one window pointer. It's possible the Frank> API changed so that both the about-to-be-destroyed window and the Frank> newly created window are available. Is yours different? No, I meant that when it's called, the instance have to compare old and new windows, ( the code from the samples, for example) to determine the action it should take. I thought it should be reasonable, that if netscape says 'go change from old window to new one' the old window should be accessible in some way. But even if it's not so, some notification on the window's own handler should be called before destroy process - in X, I think, it's DestroyNotify ( but it will be useful if only catched within the plugin, not from perl). >> And, what way did you signal the perl application? Frank> This is really the crux of the problem. I haven't found a good way Frank> to signal the application. The plugin itself is notified too late Frank> to provide a useful signal to the Perl application. You mean NPP_SetWindow here? Or DestroyNotify? It would be real bad if one couldn't reliably catch the Destroy event! But I doubt that such a mighty mouse as the X11 can't guarantee such a condition. btw - I'm planning rather not create hacks for Prima in a way it could communicate with plugin - I'd rather announce a hook for the inner event loop, which could be useful for all kind of stuff. If only that thing would be available in both tk and netscape! -- Sincerely, Dmitry |
|
From: Frank H. <fh...@av...> - 2000-09-15 22:46:43
|
On 15 Sep 2000, Dmitry Karasik wrote: > Hi Frank! > >On 14 Sep 00 at 09:54, "Frank" (Frank Holtry) wrote: > > Frank> But as I understand it (and I'm no expert on Perl internals), > Frank> Opcode doesn't control the parsing of eval'd code unless that code > Frank> itself includes a 'use Opcode'. So a malicious program can rather > Frank> easily circumvent Opcode restrictions just by eval'ing some code. > >Ah, that's why! This is not so - AFAIU from reading manuals. First of all, >Opcode restricts only future code compilation - so code like: > I think you're right. I re-read the Opcode man page, tried your code and then tested some of my applications with the plugin authorization set to 1. It turns out that the opcode that gets trapped is buried somewhere in the bowels of a widget and is part of a block of eval'd code. So, there's definitely a hole, since code that doesn't do an eval could execute pretty much anything else it wants. There was a discussion of this issue on p5p almost two years ago. I'm going to have to re-read it, because I was fairly certain that the statements I made earlier were a paraphrase of that. I hope I simply misunderstood, but I know I've heard similar comments regarding eval at the O'Reilly conferences. >-- >use Opcode; Opcode::opmask_add(Opcode::invert_opset(Opcode::opset(qw(print)))); >print "hello!\n" >-- > >will print "Hello" anyway. Interestingly, this is a model used now in the >plugin :))))) >But if you wish to stop the code from calling print(), >the wrapper should be like: >-- >use Opcode::opmask_add(Opcode::invert_opset(Opcode::opset(qw(print)))); >eval "print qq(Hello!\n)"; >--- >Thus, we have two important things: >a) - the plugin should not call just "perl filename" - unless no security >wanted. My scheme "perl -MSomeWrapper -e wrapper_init filename" >should be o.k., since SomeWrapper.pm starts first, loads opcodes and then >calls "do filename". SomeWrapper itself may suffer from security >restrictions, but I think this is feasible. It sounds feasible to me. >b) - man Opcode says: > opmask_add (OPSET) > Adds the supplied opset to the current opmask. > Note that there is currently no mechanism for > unmasking ops once they have been masked. This is > intentional. > - so, malicious program cannot call 'use Opcode; opmask_add( > full_opset)'. For now I suppose it's quite secure. > >However, the subject of security itself is a tough one, so the >real opsets and wrappers require thorough design. > Do you think more needs to be done with opsets than what is currently in np_perl.h? And you say 'wrappers' as if more than one might be needed? > Frank> I guess I need to take another look at Scriptics myself. I'm not > Frank> certain what you're referring to when you say local-based > Frank> authorization. > >I can't give you the exact url, dev.scriptics.com is not responding >somewhy, but I found there a faq reference that was like: >q:-how I'll adjust my security? a:- check the file security.ctl bla bla... >( not sure if it is right filename) > > Frank> I'd be happy to make several schemes available, if we can come up > Frank> with them. You certainly don't need tight security if all you ever > Frank> run is your own programs. And I have a hard time agreeing with the > Frank> idea that it's up to the plugin to prevent users from doing > Frank> dangerously stupid things. 'Microsoft knows best' is not my > Frank> approach of choice. > >Agree. > Frank> If I understand correctly (and I've only done a very shallow look > Frank> at this) what Scriptics did was to separate the Tk event loop from > Frank> the other code and design their widgets to display without having > Frank> the event loop running. This allowed them embed a modified > Frank> interpreter in their plugin and then essentially let Netscape do > Frank> most of the event handling. > >They do quite interesting thing - they invoke Tk loop from timer routine. >Moreover, they run the tk scripts in same process. They gain full access >to NPN, NPP and everything else, but suffer from inability to run >more than one script in the whole netscape session. >You don't even need a malicious script here - you rather say ><src embed="..."> twice in one page :))))) - and the whole thing will die. > Yes. There's a lot wrong with their plugin, not least of which is that the security is so strong (as it is in Java, too, IMHO) that it's difficult to accomplish the sort of things I'm trying to do. The problems really are due to their having built the plugin after the fact, so to speak. They tried to compensate for insecure widgets by compromising their functionality. But having an embedded interpreter so the application runs as part of the Netscape process is something I'd really like to have. I don't believe it can be done with Tk because of the event loop. But if the Prima widgets are designed from the beginning to work with both a plugin and an external event loop, I think it would be a dynamite tool. > Frank> approach with Perl/Tk. But I was speculating that it might be > Frank> possible to design a new Perl gui widget set that could be made to > Frank> work. > >You bet :)) - that's I want to do with Prima. > > Frank> I was actively working on a closely related problem and in fact I > Frank> think it's in the Unix code on sourceforge. The specific problem I should have said: the current solution is in the sourceforge code. > Frank> was trying to solve is that when Netscape does a resize, it > Frank> destroys any embedded windows it has provided. Unless the Perl > Frank> application can manage to capture the event and deal with it before > Frank> the server destroys the window, the Perl application will (usually) > Frank> die. > >Is it really? I was wandering, why NPP_SetWindow restarts the script! >But, I read the plugin guide and it says that NPP_SetWindow is called >( in this case) with two different windows, so there's a moment when both >old and new windows are alive? If it is so, then a blocking notification NPP_SetWindow( NPP instance, NPWindow * window) is what I have for the function, which only has one window pointer. It's possible the API changed so that both the about-to-be-destroyed window and the newly created window are available. Is yours different? This is an area where having an embedded application would greatly simplify the problem. As it is, what I've been doing is to query the X-server in the Perl code to construct the window heirarchy, then capture the ResizeRequest event by setting a mask on various windows, then reparenting the Tk wiget outside Netscape until the resize is completed. All very awkward and subject to race problems as I noted before. >to the script ( which responds to window id change) should work. Did you >try that? Or tk can't change the window's parent once created? Tk 800.010 and later can, I believe. Tk 400.xxx could not, to my knowlege, although it is possible to force reparenting with X11::protocol methods. >And, what way did you signal the perl application? This is really the crux of the problem. I haven't found a good way to signal the application. The plugin itself is notified too late to provide a useful signal to the Perl application. Theoretically, the X-server does it, but perl executes slowly enough that the server has time to destroy the window before the perl code can capture and respond to the resize event. Requesting notification on windows far enough down in the heirarchy can increase the odds that perl will be able to react before the server does, but it never quite reaches certainty. I looked for a spot in the plugin's calling sequence where I might be able to do the same sort of thing. But because the plugin functions are called, you might say, at the whim of Netscape, there didn't appear to me to be a way to set up the proper masks and signal the perl application. This is something that could be looked at again, though, now that I have a somewhat better grasp of how X-events work. > > Frank> I'll keep my fingers crossed for you. > >Hey, it helped! I found right keys for aout, and now it's working >just fine under freebsd-netscape. Well, some more work to do then ;) This is great news! > > -- ------------------------------------------------------------------------------- | Frank Holtry | "If you have the right attitude, interesting | | fh...@av... | problems will find you." | | | Eric S. Raymond | ------------------------------------------------------------------------------- |
|
From: Dmitry K. <dk...@pl...> - 2000-09-15 08:43:46
|
Hi Frank!
On 14 Sep 00 at 09:54, "Frank" (Frank Holtry) wrote:
Frank> But as I understand it (and I'm no expert on Perl internals),
Frank> Opcode doesn't control the parsing of eval'd code unless that code
Frank> itself includes a 'use Opcode'. So a malicious program can rather
Frank> easily circumvent Opcode restrictions just by eval'ing some code.
Ah, that's why! This is not so - AFAIU from reading manuals. First of all,
Opcode restricts only future code compilation - so code like:
--
use Opcode; Opcode::opmask_add(Opcode::invert_opset(Opcode::opset(qw(print))));
print "hello!\n"
--
will print "Hello" anyway. Interestingly, this is a model used now in the
plugin :)))))
But if you wish to stop the code from calling print(),
the wrapper should be like:
--
use Opcode::opmask_add(Opcode::invert_opset(Opcode::opset(qw(print))));
eval "print qq(Hello!\n)";
---
Thus, we have two important things:
a) - the plugin should not call just "perl filename" - unless no security
wanted. My scheme "perl -MSomeWrapper -e wrapper_init filename"
should be o.k., since SomeWrapper.pm starts first, loads opcodes and then
calls "do filename". SomeWrapper itself may suffer from security
restrictions, but I think this is feasible.
b) - man Opcode says:
opmask_add (OPSET)
Adds the supplied opset to the current opmask.
Note that there is currently no mechanism for
unmasking ops once they have been masked. This is
intentional.
- so, malicious program cannot call 'use Opcode; opmask_add(
full_opset)'. For now I suppose it's quite secure.
However, the subject of security itself is a tough one, so the
real opsets and wrappers require thorough design.
Frank> I guess I need to take another look at Scriptics myself. I'm not
Frank> certain what you're referring to when you say local-based
Frank> authorization.
I can't give you the exact url, dev.scriptics.com is not responding
somewhy, but I found there a faq reference that was like:
q:-how I'll adjust my security? a:- check the file security.ctl bla bla...
( not sure if it is right filename)
Frank> I'd be happy to make several schemes available, if we can come up
Frank> with them. You certainly don't need tight security if all you ever
Frank> run is your own programs. And I have a hard time agreeing with the
Frank> idea that it's up to the plugin to prevent users from doing
Frank> dangerously stupid things. 'Microsoft knows best' is not my
Frank> approach of choice.
Agree.
Frank> If I understand correctly (and I've only done a very shallow look
Frank> at this) what Scriptics did was to separate the Tk event loop from
Frank> the other code and design their widgets to display without having
Frank> the event loop running. This allowed them embed a modified
Frank> interpreter in their plugin and then essentially let Netscape do
Frank> most of the event handling.
They do quite interesting thing - they invoke Tk loop from timer routine.
Moreover, they run the tk scripts in same process. They gain full access
to NPN, NPP and everything else, but suffer from inability to run
more than one script in the whole netscape session.
You don't even need a malicious script here - you rather say
<src embed="..."> twice in one page :))))) - and the whole thing will die.
Frank> approach with Perl/Tk. But I was speculating that it might be
Frank> possible to design a new Perl gui widget set that could be made to
Frank> work.
You bet :)) - that's I want to do with Prima.
Frank> I was actively working on a closely related problem and in fact I
Frank> think it's in the Unix code on sourceforge. The specific problem I
Frank> was trying to solve is that when Netscape does a resize, it
Frank> destroys any embedded windows it has provided. Unless the Perl
Frank> application can manage to capture the event and deal with it before
Frank> the server destroys the window, the Perl application will (usually)
Frank> die.
Is it really? I was wandering, why NPP_SetWindow restarts the script!
But, I read the plugin guide and it says that NPP_SetWindow is called
( in this case) with two different windows, so there's a moment when both
old and new windows are alive? If it is so, then a blocking notification
to the script ( which responds to window id change) should work. Did you
try that? Or tk can't change the window's parent once created?
And, what way did you signal the perl application?
Frank> I'll keep my fingers crossed for you.
Hey, it helped! I found right keys for aout, and now it's working
just fine under freebsd-netscape. Well, some more work to do then ;)
--
Sincerely,
Dmitry
|
|
From: Frank H. <fh...@av...> - 2000-09-14 15:55:08
|
On 14 Sep 2000, Dmitry Karasik wrote: Dmitry, This is excellent discussion! I'm not certain I understand everything you're proposing, so I'll have some questions. But my basic position is that if you've got an idea you think will work, let's try it. There are a number of Perl users who'd like to have the functionality of the plugin, but the security issues make them wary of using it. If we can come up with a really robust way to guarantee that browsing a program from another site won't damage the local machine, a lot more people will be interested in using it. > Hi Frank! > >On 13 Sep 00 at 15:02, "Frank" (Frank Holtry) wrote: > > Frank> If your library can avoid using the more > Frank> dangerous Perl opcodes,then you could definitely use Opcode for > Frank> security. > >I thought that just using Opcode would be enough for a good balance >between security and productivity; I thought that eval itself is not >a problem, while it contains a legal code. But that's rather a technical Yes. I may misunderstand what you're thinking here, so forgive me if I do. If there were a way to examine what is being eval'd and only allow 'safe' evals to happen, the problem could be dealt with. But as I understand it (and I'm no expert on Perl internals), Opcode doesn't control the parsing of eval'd code unless that code itself includes a 'use Opcode'. So a malicious program can rather easily circumvent Opcode restrictions just by eval'ing some code. >side of the implementation. My point is, that cgi authorization is only >one of many ways to do things; and from my point of view it's more confusing >than helpful. I think that good thing is to implement ( BTW, like Based on the handful of users who've tried the plugin, I'd tend to agree that the CGI authorization is confusing. Most of them have found it to some degree awkward to set up and get working. If you have another idea, lets try it. >Scriptics that you mentioned does) local security settings; and cgi >authorization will be just an extension. Currently we have no such scheme, I guess I need to take another look at Scriptics myself. I'm not certain what you're referring to when you say local-based authorization. But I'm certainly willing to try it if it makes sense. >and the only possiblilities are either to have cgi-auth or to have none. I'd be happy to make several schemes available, if we can come up with them. You certainly don't need tight security if all you ever run is your own programs. And I have a hard time agreeing with the idea that it's up to the plugin to prevent users from doing dangerously stupid things. 'Microsoft knows best' is not my approach of choice. >If we agree to change this, the local-based authorization is a good thing >IMHO. > > > > Frank> Another alternative I looked into and even experimented with a > Frank> little is what Scriptics uses for Tcl/Tk. It's a custom > Frank> interpreter embedded in the plugin that only recognizes the 'safe' > Frank> subset of Tcl commands. It also handles events differently to > Frank> avoid the problem of two event loops trying to maintain control > Frank> simultaneously (one in Netscape, one in the plugin). You might > Frank> find their approach interesting. You can get the source from > Frank> http://dev.scriptics.com/software/plugin. > >Yes, it is really interesting, but is not applicable to perl, I think. >Problems begin when plugin have to handle more than one instance of perl > - in one process. When, for example, one task call _exit(), the whole >plugin will die. And, the perl core itself is not thread-safe that way; >moreover, such a scheme would require the existence of the event loop - >but what if program doesn't have any? If I understand correctly (and I've only done a very shallow look at this) what Scriptics did was to separate the Tk event loop from the other code and design their widgets to display without having the event loop running. This allowed them embed a modified interpreter in their plugin and then essentially let Netscape do most of the event handling. As you say, it would take a lot of modification of a Perl interpreter and of the Tk libraries and modules to use this approach with Perl/Tk. But I was speculating that it might be possible to design a new Perl gui widget set that could be made to work. >Of course, running all processes in one is tempting, but I see no way >how to implement this model. > >But the worse thing is yet to come - such an integration will require >the awareness of the client process, and it's IPC model. No matter, >tcl or perl-tk it will be using, the code base have to be altered heavily. >That doesn't matter when you're running only external windows, with no >communication to the browser - but this is not interesting! I succeed >integrating perl widgets into navigator window, but I want more - page >and content interactions, and maybe java. I was actively working on a closely related problem and in fact I think it's in the Unix code on sourceforge. The specific problem I was trying to solve is that when Netscape does a resize, it destroys any embedded windows it has provided. Unless the Perl application can manage to capture the event and deal with it before the server destroys the window, the Perl application will (usually) die. In the code that's on CPAN, we punted. We used a facility within the plugin to restart the Perl application after a resize. This is ok for applications that only want to display pretty pictures, but for anything trying to display the results of serious processing it's disastrous. So, I was trying to capture the X-window events as they propagated through the heirarchy and let the Perl application take some action to preserve it's state. I got this working about 95% of the time, but it's always a race between the X-server trying to destroy and cleanup, and the Perl application (which runs at a lower priority) trying to catch and respond to the event. Sometimes, the server wins. Maybe, with careful design of the application, I could work around the remaining instances, but it would certainly be better if Netscape were better behaved. > >I am now trying to make the plugin accepting external messages inside >it's internal window event handler - so it could also handle external >requests to NPN_XXX routines, which - note! - aren't thread-safe also. If you manage to solve this problem without serious changes to Netscape itself, my hat's off to you! Mozilla appears to have added some additional NPN_XXX routines to make this a little easier, but this seems to me to be the most serious weakness in the Netscape plugin model. It doesn't provide enough communication between the plugin and the browser, especially FROM the plugin TO the browser. >From the side of a perl program, its own event loop will be listening >to the plugin messages, and the exact protocol should be system-specific. >But that is a bad thing, because you have to hack tk's event loop code - >if you need more than just an embedded widget, of course. > My original need for the plugin was to enable launching of Source Configuration Management tools from a web page. Displaying nice-looking widgets isn't quite enough by itself to meet the need. >BTW - I still can't compile the plugin under freebsd; right now my machine >is busy compiling mozilla port - maybe it will work that way? > I'll keep my fingers crossed for you. > -- ------------------------------------------------------------------------------- | Frank Holtry | "If you have the right attitude, interesting | | fh...@av... | problems will find you." | | | Eric S. Raymond | ------------------------------------------------------------------------------- |
|
From: Dmitry K. <dk...@pl...> - 2000-09-14 13:35:14
|
Hi Frank! On 13 Sep 00 at 15:02, "Frank" (Frank Holtry) wrote: Frank> If your library can avoid using the more Frank> dangerous Perl opcodes,then you could definitely use Opcode for Frank> security. I thought that just using Opcode would be enough for a good balance between security and productivity; I thought that eval itself is not a problem, while it contains a legal code. But that's rather a technical side of the implementation. My point is, that cgi authorization is only one of many ways to do things; and from my point of view it's more confusing than helpful. I think that good thing is to implement ( BTW, like Scriptics that you mentioned does) local security settings; and cgi authorization will be just an extension. Currently we have no such scheme, and the only possiblilities are either to have cgi-auth or to have none. If we agree to change this, the local-based authorization is a good thing IMHO. Frank> Another alternative I looked into and even experimented with a Frank> little is what Scriptics uses for Tcl/Tk. It's a custom Frank> interpreter embedded in the plugin that only recognizes the 'safe' Frank> subset of Tcl commands. It also handles events differently to Frank> avoid the problem of two event loops trying to maintain control Frank> simultaneously (one in Netscape, one in the plugin). You might Frank> find their approach interesting. You can get the source from Frank> http://dev.scriptics.com/software/plugin. Yes, it is really interesting, but is not applicable to perl, I think. Problems begin when plugin have to handle more than one instance of perl - in one process. When, for example, one task call _exit(), the whole plugin will die. And, the perl core itself is not thread-safe that way; moreover, such a scheme would require the existence of the event loop - but what if program doesn't have any? Of course, running all processes in one is tempting, but I see no way how to implement this model. But the worse thing is yet to come - such an integration will require the awareness of the client process, and it's IPC model. No matter, tcl or perl-tk it will be using, the code base have to be altered heavily. That doesn't matter when you're running only external windows, with no communication to the browser - but this is not interesting! I succeed integrating perl widgets into navigator window, but I want more - page and content interactions, and maybe java. I am now trying to make the plugin accepting external messages inside it's internal window event handler - so it could also handle external requests to NPN_XXX routines, which - note! - aren't thread-safe also. From the side of a perl program, its own event loop will be listening to the plugin messages, and the exact protocol should be system-specific. But that is a bad thing, because you have to hack tk's event loop code - if you need more than just an embedded widget, of course. BTW - I still can't compile the plugin under freebsd; right now my machine is busy compiling mozilla port - maybe it will work that way? -- Sincerely, Dmitry |
|
From: Frank H. <fh...@av...> - 2000-09-13 21:02:32
|
Dmitry, As Steve pointed out, we do use Opcode to provide some increased security for applications other than Tk. But Tk makes extensive use of eval, which is about as wide open a security hole as Perl provides. If your library can avoid using the more dangerous Perl opcodes,then you could definitely use Opcode for security. Another alternative I looked into and even experimented with a little is what Scriptics uses for Tcl/Tk. It's a custom interpreter embedded in the plugin that only recognizes the 'safe' subset of Tcl commands. It also handles events differently to avoid the problem of two event loops trying to maintain control simultaneously (one in Netscape, one in the plugin). You might find their approach interesting. You can get the source from http://dev.scriptics.com/software/plugin. I'm also looking at providing signed applications using pgp. This won't make the application any more secure, but if it's done correctly, it will make it possible to identify the author and place responsibility on them for any problems. BTW, Steve, it occurs to me that I haven't really told you what Dmitry is doing. I apologize for that; it would have made this discussion more understandable. He can fill you in on the details, but essentially they're building a non-Tk Perl gui library. He's interested in the plugin for it and volunteered to work on the Win32 version. Frank On 13 Sep 2000 Dmi...@pl... wrote: > >Hi! > > During my code digging with the plugin, I disabled the authorization >feature (just to make my work simplier). But from my point of view, this >part is not necessary at all - of course, protection is a tough problem, >but I don't think it should be solved like this. I would suggest rather >java-like protection, when no local operations are permitted ( >feasuble with -T and/or use Opcode). And, the additional security >settings would be accessible for locally - like, MSIE does, assigning >different site groups to the different security groups. > > What would you say if I try to implement this scheme instead of >cgi-authorization? The reason I want to do this hard way is that I >would like to re-write both win32 and X parts, merging the code from >both platforms. > > -- ------------------------------------------------------------------------------- | Frank Holtry | "If you have the right attitude, interesting | | fh...@av... | problems will find you." | | | Eric S. Raymond | ------------------------------------------------------------------------------- |
|
From: Steve L. <so...@le...> - 2000-09-13 14:24:18
|
Dmi...@pl... wrote: > > Hi! > > During my code digging with the plugin, I disabled the authorization > feature (just to make my work simplier). But from my point of view, this > part is not necessary at all - of course, protection is a tough problem, > but I don't think it should be solved like this. I would suggest rather > java-like protection, when no local operations are permitted ( > feasuble with -T and/or use Opcode). And, the additional security > settings would be accessible for locally - like, MSIE does, assigning > different site groups to the different security groups. > > What would you say if I try to implement this scheme instead of > cgi-authorization? The reason I want to do this hard way is that I > would like to re-write both win32 and X parts, merging the code from > both platforms. Besides CGI authorization, Frank already has opcode restrictions - in fact the cgi program is responsible for assigning the opcode security level! The problem appears to be that to do anything useful in Tk you need to allow many of the "evil" opcodes..... Steve |
