I totally forgive the guy who missed the bounds check, he made a human
mistake, we've all been there.
What I can't forgive is the culture which prides cryptic pointer acrobatics
and eschews verification because "Good Programmers don't make mistakes".

Thanks,
Caleb


On 04/15/2014 12:47 PM, jindq1 wrote:
> I'm sure they felt the same way when they introduced their features until
> someone came along and served them humble pie. As for "completely screwed
> up by all of the big players", there are no "big players", just passionate,
> overworked human beings like yourself. You can't ask for perfection, just
> humility when finding out a mistake-- something I think the community and
> those responsible have all handled nicely this time around.
>
>
> On Tue, Apr 15, 2014 at 5:44 AM, Caleb James DeLisle <cjd@???> wrote:
>
>> Here's a pretty nice review of various SSL libraries.
>> http://tstarling.com/blog/2014/04/ssl-implementations-compared/
>>
>> I tend to agree with him, sadly, if you need SSL probably your only
>> option is running a little Java proxy in front of your webserver.
>>
>> Note that this is the fault of the SSL specification too, they created
>> what is effectively a Ping message, nested inside of a generic SSL
>> message and they added a duplicated length field. Cjdns also contains
>> variable length ping messages, there is no ambiguity because they get
>> their length from their container.
>>
>> In cjdns, all data which comes in from the world is immediately placed
>> into Message structures which are effectively grow-down stacks, they
>> have a length, a pointer to the head of the stack and a "padding"
>> number which represents how far the stack can grow. Accesses to the
>> data in this stack are through push and pop functions which contain
>> bounds checks.
>> https://github.com/cjdelisle/cjdns/blob/crashey/wire/Message.h
>> A good example of this is in the DNS message parser where every read
>> and every write is managed by Message_pop() and Message_push().
>> https://github.com/cjdelisle/cjdns/blob/crashey/interface/DNSServer.c
>>
>> I'm not totally tooting my own horn here, my biggest point is to ask
>> how can something that I managed to get more or less right be so
>> completely screwed up by all of the big players?!
>>
>>
>> Thanks,
>> Caleb
>>
>>
>> On 04/14/2014 05:53 PM, Troy Benjegerdes wrote:
>>> The best part was the 'update your bitcoinz, because someone can steal
>>> them if you use the completely unncecssary openssl payment protocol'.
>>> Fortunately many altcoins have been saved by sheer laziness of not
>>> updating to the latest pre-hacked version.
>>>
>>> So does Theo have a decent SSL implementation in OpenBSD? Is gnutls any
>>> good?
>>>
>>> On Fri, Apr 11, 2014 at 10:07:34AM +0200, Caleb James DeLisle wrote:
>>>> Heartbleed reads up to 64k of memory, crossing 16 page boundaries
>>>> into "unallocated space" but it never triggers a segfault even
>>>> on systems with hardened malloc().
>>>>
>>>> Theo de Raadt comments on OpenSSL's bypass of the OpenBSD secure
>> malloc()
>>>> http://article.gmane.org/gmane.os.openbsd.misc/211963
>>>>
>>>> And more about exactly how it works:
>>>> http://www.tedunangst.com/flak/post/heartbleed-vs-mallocconf
>>>>
>>>> And why it's impossible to turn it off:
>>>> http://www.tedunangst.com/flak/post/analysis-of-openssl-freelist-reuse
>>>>
>>>>
>>>> A missed bounds check is an accident, a pattern of insecure design
>>>> practices is a scandal.
>>>>
>>>>
>>>> _______________________________________________
>>>> unSYSTEM mailing list: http://unsystem.net
>>>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>>
>> _______________________________________________
>> unSYSTEM mailing list: http://unsystem.net
>> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>>
>
>
>
> _______________________________________________
> unSYSTEM mailing list: http://unsystem.net
> https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
>