Bennett Todd bet@rahul.net 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