home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / tcl / 2255 < prev    next >
Encoding:
Text File  |  1992-12-27  |  1.5 KB  |  37 lines
  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!walter!news
  3. From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
  4. Subject: Re: Tcl as a safe multimedia mail language (was Re: Insecurity of tk)
  5. Message-ID: <1992Dec28.004651.24596@walter.bellcore.com>
  6. Sender: news@walter.bellcore.com
  7. Nntp-Posting-Host: bambam.bellcore.com
  8. Organization: Bellcore
  9. Date: Mon, 28 Dec 92 00:46:51 GMT
  10. Lines: 25
  11.  
  12. Excerpts from netnews.comp.lang.tcl: 25-Dec-92 Tcl as a safe multimedia
  13. ma.. Karl Lehenbauer@NeoSoft. (1272)
  14.  
  15. > You can test some of your ideas with respect to Tcl as a safe multimedia
  16. > mail language without resorting to C at all -- if you use "rename" and
  17. > rename a command to "", it is effectively deleted from the interpreter.
  18.  
  19. True, but dangerous.  Before I would depend on this approach in a
  20. production implementation, I would want to have a Tcl command that gave
  21. me the names of all currently-defined Tcl commands.  I could then use an
  22. "OK" list instead of a "DANGEROUS" list, which sounds like a much safer
  23. approach.
  24.  
  25. > It would be nice if your support procs could read and write files and such,
  26. > while procs embedded in mail, or whatever, could only access the restricted
  27. > set.
  28.  
  29. Yeah, but this can get real tricky in the implementation.  For example,
  30. one could imagine letting the user define procs which could use the more
  31. powerful feature set and could in turn be called by mail procs, but this
  32. effectively allows each user to redefine the language in idiosyncratic
  33. and security-endangering ways, which I think would be a bad idea. --
  34. Nathaniel
  35.  
  36.  
  37.