home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / lang / tcl / 2237 < prev    next >
Encoding:
Text File  |  1992-12-23  |  2.0 KB  |  45 lines

  1. Newsgroups: comp.lang.tcl
  2. Path: sparky!uunet!walter!news
  3. From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
  4. Subject: Re: Insecurity of tk
  5. Message-ID: <1992Dec23.172819.8380@walter.bellcore.com>
  6. Sender: news@walter.bellcore.com
  7. Nntp-Posting-Host: bambam.bellcore.com
  8. Organization: Bellcore
  9. Date: Wed, 23 Dec 92 17:28:19 GMT
  10. Lines: 33
  11.  
  12. Excerpts from netnews.comp.lang.tcl: 23-Dec-92 Re: Insecurity of tk Sean
  13. McLinden@andrew.cmu (1134)
  14.  
  15. > A, potentially, bigger security concern is that it seems pretty obvious
  16. > that a slick MIME interface could be written to allow tcl/tk scripts to
  17. > be used as interactive mail. The CMU Andrew project did just such a think
  18. > with Atk and, later NESS. The difficulty lies in having an interpreter which
  19. > can detect potential security problems before running the application or which
  20. > could run the application in a secure mode so that you don't have people
  21. > sending
  22. > Trojan horses to each other.
  23.  
  24. Yes, this is why the MIME standard and the metamail documentation warn
  25. you in very dire terms about defining your own too-powerful extensions
  26. to MIME.  It can be a very dangerous thing.
  27.  
  28. One of my own research projects, in recent years, has focused on the
  29. design of a programming language for mail-based applications that is
  30. limited in such a way as to make it NOT be a security problem.  The
  31. resulting language, called ATOMICMAIL, was described in a paper of mine
  32. at last month's CSCW conference.  A plain text copy of that paper is
  33. available, for anyone interested, via anonymous ftp from
  34. thumper.bellcore.com in pub/nsb/CWCW-ATOMICMAIL.txt.
  35.  
  36. I have also thought, in recent months, that Tcl/TK might be a better
  37. basis for a secure mail-based programming language than LISP, which is
  38. the language model for ATOMICMAIL.  Basically, what we'd need would be a
  39. sort of castrated version of the Tcl/TK interpreter, in which all
  40. potentially dangerous actions were removed or replaced with less
  41. dangerous variants.  If anyone else is interested in pursuing this idea,
  42. I'd be delighted to collaborate...  -- Nathaniel
  43.  
  44.  
  45.