<br><br><div class="gmail_quote">On Dec 29, 2007 2:08 PM, John M McIntosh &lt;<a href="mailto:johnmci@smalltalkconsulting.com">johnmci@smalltalkconsulting.com</a>&gt; wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
I think perhaps the SqueakELib project should tackle this.<br><br>Squeak is not secure and does not pretend to be secure, although there<br>are attempts to lock down file/socket access to keep casual users from<br>doing undesirable things. &nbsp;However other forks of the VM like
<br>SqueakELib want:<br><br>&quot; a multithreaded vm for a secure, distributed object implementation&quot;<br><br>note the word *secure*<br><br>buffer overflows, bytecode hacks, well those all valid tactics against<br>*secure* VMs..
<br><br>so go over there and ask...<br><a href="http://wiki.squeak.org/squeak/6011" target="_blank">http://wiki.squeak.org/squeak/6011</a><br><br>Otherwise if you can compile smalltalk code that causes the VM to<br>crash, then we are always interested, plus you get bonus points if
<br>that causes VisualWorks to crash too.<br></blockquote></div><br><br>Sure - so compiler-generated code that can crash the VM is considered a valid Squeak bug, but hand-crafted malicious bytecodes that crash Squeak are considered to be the programmer&#39;s fault.
<br><br>My project&#39;s page is at <a href="http://gulik.pbwiki.com/SecureSqueak">http://gulik.pbwiki.com/SecureSqueak</a>. I&#39;m not ready to start on modifying the VM, but when I get that far, I&#39;ll let people like Ron Teitelbaum know.
<br><br>Gulik.<br><br clear="all"><br>-- <br><a href="http://people.squeakfoundation.org/person/mikevdg">http://people.squeakfoundation.org/person/mikevdg</a><br><a href="http://gulik.pbwiki.com/">http://gulik.pbwiki.com/
</a>