On Thu, Aug 14, 2008 at 8:37 AM, Elf [EMAIL PROTECTED] wrote:
the problem is the procedures starting at lines 146 and 148 in svn head,
getb and getw. theyre not checking for eof-object, which would cause this
behaviour. fetch isnt checking either, but it needs to be at getb level,
cause
the problem is the procedures starting at lines 146 and 148 in svn head,
getb and getw. theyre not checking for eof-object, which would cause this
behaviour. fetch isnt checking either, but it needs to be at getb level,
cause char-integer against eof-object isnt so good. the weird question
On Wed, Aug 13, 2008 at 8:38 AM, Joshua Griffith
[EMAIL PROTECTED] wrote:
Hello,
When a serialized object gets corrupted or truncated (which often occurs
when it is transmitted over a TCP connection), attempting to deserialize
that object results in a Bus error and immediate program
Yes, I thought about just using a CRC, but I couldn't figure out the
case of a maliciously formed or manipulated input, where the
serialized object is corrupted, but the checksum is correct. It seems
like the only solution would be to further protect the deserialization
procedure.
The following lines demonstrate the problem:
(use s11n)
(deserialize (open-input-string \f))
-Josh
On Aug 13, 2008, at 4:30 AM, felix winkelmann wrote:
On Wed, Aug 13, 2008 at 8:38 AM, Joshua Griffith
[EMAIL PROTECTED] wrote:
Hello,
When a serialized object gets corrupted or truncated
