Bennett Todd <[EMAIL PROTECTED]> writes:
> Would it be worth composing an announcement of this for venues like
> bugtraq and full-disclosure? Or do you think most lsh users are on
> lsh-bugs?
I *hope* all people that use lshd in production environments are
subscribed to this mailinglist. But it would certainly make sense to
post an announcement on security vulnerability fora.
But I think my top priority for lsh work the next few days will be to
get new 1.4.3 and 1.5.3 releases out; writing an announcement is
secondary.
> On a separate topic, I've been chatting with someone else, and he
> pointed out that a somewhat different abstraction could be more
> robust; rather than having an open, visible buffer data structure
> into which code can directly write,
The abstractions in this piece of code with it's fixed size buffer is
not typical for lsh. Most "buffer management" is in the single
function ssh_format, which takes a format string and arguments,
calculates and allocates the needed space, formats the data into the
newly allocated space, and then at the end asserts() that actual
length matches exactly the length which was computed earlier. Callers
usually need not care about bounds checking.
If there are any principles behind this design it's
(1) Try to keep the allocation and bounds checking in one place. Or
at least in *few* places, there are a few more but ssh_format.
(2) Keep things simple. I don't believe in complex frameworks to
protect modules from each other (at least I don't believe in
that if the modules are still running in their own address
space). Frameworks are useful only when they make the code
simpler.
Regards,
/Niels
_______________________________________________
lsh-bugs mailing list
[EMAIL PROTECTED]
http://lists.lysator.liu.se/mailman/listinfo/lsh-bugs
