Re: Heartbleed

["Pascal J. Bourguignon" <pjb@informatimago.com>]

Maciej Sobczak <see.my.homepage@gmail.com> writes:

> W dniu piątek, 11 kwietnia 2014 04:39:18 UTC+2 użytkownik Charles H. Sampson napisał:
>
>> According to Wikipedia, the Heartbleed bug in OpenSSL is caused by
>> two errors: Lack of bounds checking and failure to verify that the
>> heartbeat request was valid. Whom does one express one's indignation to?
>
> The following page answers your question:
>
> http://www.openssl.org/source/license.html
>
> The part written in CAPITAL LETTERS is specifically focused on this.
>
>> The insistence of many in our "profession" on using C and its decendents
>> is the reason I qualify the word "profession" when writing about
>> software developers.
>
> Every general statement has some exceptions. Even though *in general*
> you are right, in this particular case things work a bit
> differently. OpenSSL is ntended as a common component that is used by
> everybody else. In order to achieve this you need to choose the
> technology that is a common denominator, both in terms of the ability
> to link with it and in terms of the availability of toolchains.
> Now, you might argue that is is possible to write the library in Ada
> in such a way that it can be reused from other languages, it is not
> easy to do so, especially if you take into account the
> (un)availability of language runtime. The biggest issue, however, is
> the availability of compilers.
>
> Saying that this stuff should have been written in Ada is pointless.


Yes, there's nothing magical in C, one can write libc in any language.

Furthermore, the C standard all define such constructs as illegal,
errors or leave their semantics as undefined.

Therefore the problem is not with the language, but much more with the
C programmers and C compiler programmers, because it would be perfectly
valid a compiler, one that would add run-time bound checks (in addition
to compilation time errors or warnings), with the associated
("undefined" by the language, but defined by the specific C
implementation/compiler) corresponding exception processing.

(And given the memory caches and pilelined processor architectures we
have nowadays, it wouldn't even have any noticeable performance hit).



>> Acting on a message without validating it is
>> equally incomprenhensible to me.
>
> That's right.
>
>> For the latter, someone needs a severe rebuke on his next
>> performance review, at the least.
>
> I am not aware of performance reviews for people who voluntarily
> contribute on their free time. Not sure if that was the case for this
> particular piece of code, but anyway, read the license again. The fact
> that somebody wrote crappy piece of code is part of the whole problem
> - the other part is that we (yes, the whole world) choose to use
> it. Who is to blame?

Definitely.

That said, we get to see and know it's a piece of shit: we've got the
freedom to do so.  With proprietary software, it's the same, only we
don't know it.

But when you want to write correct code, you explode the dead lines and
get fired long before you can complete it.


-- 
__Pascal Bourguignon__
http://www.informatimago.com/
"Le mercure monte ?  C'est le moment d'acheter !"