OpenSSL development (Heartbleed)

OpenSSL development (Heartbleed)

[Alan Browne]

Good article in the NYT:

http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Nasser M. Abbasi]

On 4/19/2014 9:31 AM, Alan Browne wrote:
>
> Good article in the NYT:
>
> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business
>

Ok, I read the article. The main point seems to
blame lack of funding from corporation that use
OpenSSL which is developed as open source by
volunteers.

Some student submitted a patch on eve of 2011
with the bug. The patch was "vetted" by a more
senior developer later on, And so now we have it.

I do not see anywhere, how is regression testing is
done in this picture. Is there is lab full of networks
and computers used to run thousands of regression
tests each time a new software update is made? What
was the result of these regression tests at that time?
Where is the report on that? The problem seems to
be with lack of test coverage and weak testing
methodology used. May be due to lack of resourcesm
or for other reasons.

Yes, big companies need to donate more money to
openSSL, but also testing should be improved.

Other than the problem with using C, more internal
testing is needed by open source developers. (Even more,
since they use C, and not Ada :).

--Nasser

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 11:06 , Nasser M. Abbasi wrote:
> On 4/19/2014 9:31 AM, Alan Browne wrote:
>>
>> Good article in the NYT:
>>
>> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business
>>
>>
>
> Ok, I read the article. The main point seems to
> blame lack of funding from corporation that use
> OpenSSL which is developed as open source by
> volunteers.
>
> Some student submitted a patch on eve of 2011
> with the bug. The patch was "vetted" by a more
> senior developer later on, And so now we have it.
>
> I do not see anywhere, how is regression testing is
> done in this picture. Is there is lab full of networks
> and computers used to run thousands of regression
> tests each time a new software update is made? What

Testing?

Bwahahahaahahahahahahahaahahahaaaaaaaaaa aaaa  aaaa   a a

> was the result of these regression tests at that time?
> Where is the report on that? The problem seems to
> be with lack of test coverage and weak testing
> methodology used. May be due to lack of resourcesm
> or for other reasons.

Resources - or rather how they are employed - is the primary issue.

>
> Yes, big companies need to donate more money to
> openSSL, but also testing should be improved.
>
> Other than the problem with using C, more internal
> testing is needed by open source developers. (Even more,
> since they use C, and not Ada :).

Language is not the issue.  The issue is a lack of defined requirements 
which leads to design, documentation, testing, etc.  For something as 
critical as SSL one would hope that more care would go into change 
management and testing.  But that's a laugh in open source - everyone 
wants to code - not document.

Someone receiving $2K a year (if that) is not going to spend much time 
editing and revising requirements... and students working on it see 
their code "working" and that is sufficient.  Time to move on to getting 
your paws up Susie's skirt or finding a job at McDonald's.

Apple went a different direction.  Not especially for security reasons 
but that they found OpenSSL bloated and no longer fitting their future 
needs.

http://appleinsider.com/articles/14/04/18/how-apple-dodged-the-heartbleed-bullet

But they still do everything in C variants and that is not going to change.

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 16:31, Alan Browne wrote:
>
> Good article in the NYT:
>
> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business
>

An exquisite example of how journalism keeps contributing
to tactically keeping everyone uninformed, for money (ads,
or subscription).

But, well, it ends in fundraising, for whatever allegedly
good thing having somehow to do with OpenSSL.

Scene:
   We've got an accident! (A big bug in who-knows-what causing ...).

  Starring:
   software people,
   politicians,
   companies,
   passwords,
   funding.


Unquestioned semitheories, by emphasis:
  - Open Source means unpaid, voluntary weekend work.
  - Open Source means eyeballs looking at others' software,
    hence quality assurance.

So vastly unspecific, incomplete, and untestable as stated, this is a good
start for putting opinions on just something in contrast; the conditional
of the second hypothesis is in and of itself good for rhetoric.
The author indicates that there is no clear indication of the actual
harm done (while at about the same time some lad finds himself arrested
for doing harm (sniffing social security numbers) using the Heartbleed bug).

Quoted "expert" (E. S. Raymond) says: there weren't any eyeballs
watching the software.
(Misquote? After all, the author names the reviewing software person.)
But the expert is popular and controversial, so he's a perfect
journalistic asset (triggers Raymond gossip and Raymond controversy).

Finally, the author announces a fundraising project of said expert.
Good advertising.

In between, reports of booing, bemoaning, and demanding; journalist
tries to establish a scape goat (OpenSSL users don't fund!).
No proof, no clear indication of causation, but alluding in style.
By saying that OpenSSL is not a well funded project, she obviously
tries to imply that this is (a) true in effect, and (b) that funding
prevents bugs. (a): most of OpenSSL does exist only after work
of payed employees. (b): See bugs discovered at the same time in well
funded MS Word and MS Outlook projects, of similar reach.

Re: OpenSSL development (Heartbleed)

[Yannick Duchêne (Hibou57)]

Le Sat, 19 Apr 2014 17:36:17 +0200, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:
>
> In between, reports of booing, bemoaning, and demanding; journalist
> tries to establish a scape goat (OpenSSL users don't fund!).
> No proof, no clear indication of causation, but alluding in style.
> By saying that OpenSSL is not a well funded project, she obviously
> tries to imply that this is (a) true in effect,

That's a well established fact in the software area, so the assumption is  
honest enough.

> and (b) that funding
> prevents bugs.(a): most of OpenSSL does exist only after work
> of payed employees. (b): See bugs discovered at the same time in well
> funded MS Word and MS Outlook projects, of similar reach.

Obviously, funding does not make miracles but neither free as in free‑beer  
do. However you are more likely to get people sticking to good methods,  
give time and energy for this, if they get something in return.

Funding does not make people do a good job automatically, but it still  
make it more likely to be than with the opposite.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote:
> Le Sat, 19 Apr 2014 17:36:17 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit:
>>
>> In between, reports of booing, bemoaning, and demanding; journalist
>> tries to establish a scape goat (OpenSSL users don't fund!).
>> No proof, no clear indication of causation, but alluding in style.
>> By saying that OpenSSL is not a well funded project, she obviously
>> tries to imply that this is (a) true in effect,
>
> That's a well established fact in the software area, so the assumption is honest enough.

That Funding = Quality_Assurance is a repeatedly established
belief in talking about the "software area", so the only thing
one can honestly assume is that people are going to repeat it.

All of: the discovery of a bug, the review process, if any, are
empirically observable facts, to some extent, though not always
publicly observable. The results will depend on the instruments of
observation. The interpretation of results can be subject to review
etc. (Rarely, if ever, do we get to see the "issues" that affect
the most widespread OS of all, e.g.) Examples include the Heartbeat
bug (OpenSSL), the GotoFail bug (Apple), the RTF bug, and several
others on record at the CVE database, things known by prefixes
"KB" and "HT", etc.


>> and (b) that funding
>> prevents bugs.(a): most of OpenSSL does exist only after work
>> of payed employees. (b): See bugs discovered at the same time in well
>> funded MS Word and MS Outlook projects, of similar reach.
>
> Obviously, funding does not make miracles but neither free as in free‑beer do.

This says what doesn't produce miracles: both funding and
not funding, hence everything. A rhetorically and politically
usable  statement, though pointless.

It wasn't claimed that free or free-beer would would produce
miracles! That claim would be journalistic implication.

> However you are more likely to get people sticking to good methods, give time and energy for this, if they get something in return.

Well, that again makes for a hypothesis that is so unspecific
that it fits the same bill: correlation turned causal based on
likelihood, ceteris paribus.
E.g., what are the specifics in terms of work hours, pay, and
project characteristics? Do we have control-group like evidence?

Can you substantiate your claim a little?

Re: OpenSSL development (Heartbleed)

[Yannick Duchêne (Hibou57)]

Le Sat, 19 Apr 2014 18:34:13 +0200, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:

>> That's a well established fact in the software area, so the assumption  
>> is honest enough.
>
> That Funding = Quality_Assurance is a repeatedly established
> belief in talking about the "software area", so the only thing
> one can honestly assume is that people are going to repeat it.

Not a belief, a practical fact. It happens I discovered bugs in some misc  
open‑source software, but either did not solved/investigated it, because I  
have enough things to solve in my own life. If helping others in solving  
this would have make them help/support me in return, this would have been  
different. Another variant is when it happened I discovered bugs,  
investigated these, proposed a fix, and the fix was rejected for  
mysterious reasons and I did not insist because I did not have time to  
fight for this, for similar reasons as above.

That's just real life. There is a well known philosophy in the Ada world,  
which cleverly says “programming is a human activity” with a strong  
emphasis on “human” and it's characteristics, which means, it's not  
something outside of human contingencies.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 19:06, Yannick Duchêne (Hibou57) wrote:
> Le Sat, 19 Apr 2014 18:34:13 +0200, Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de> a écrit:
>
>>> That's a well established fact in the software area, so the assumption is honest enough.
>>
>> That Funding = Quality_Assurance is a repeatedly established
>> belief in talking about the "software area", so the only thing
>> one can honestly assume is that people are going to repeat it.
>
> Not a belief, a practical fact. It happens I discovered bugs in some misc open‑source software,

> but either did not solved/investigated it, because I have enough things to solve in my own life.

> If helping others in solving this would have make them help/support me in return, this would have been different.

So you were presuming that if you had done something, they would
not have done something in return to help you?

Your fact so far seems this: "In my real life I didn't do
something, because I didn't expect returns." OK.

Do we have reasons, not opinions, to generalize this description
in ways that are demonstrably applicable to cases like Heartbleed?
So that economic decisions can be based on facts? (If they ever are.)

> Another variant is when it happened I discovered bugs, investigated these, proposed a fix,

> and the fix was rejected for mysterious reasons and I did not insist because

>I did not have time to fight for this, for similar reasons as above.

What does funding or not of their project have to do with
reasons forrejection? And what does funding or not of their
project have to do with rejection or not? And what does funding
or not of your project have to do with (reasons for) rejection?

Apple, for example, is known to be secretive about how they will
finally react, or not react, to bug reports. They are well funded.

Thus it might be an ideal situation when funding means maintenance
and (responsive) support, but I don't see that funding entails
the latter two.
  
> That's just real life. There is a well known philosophy in the Ada world, which cleverly says “programming is a human activity” with a strong emphasis on “human” and it's characteristics, which means, it's not something outside of human contingencies.

Right, and rhetoric is a well established human activity, too.
Human activities is what may or may not turn the hypothesis that
Funding = Quality_Assurance into a fact, in each case.

Re: OpenSSL development (Heartbleed)

[Yannick Duchêne (Hibou57)]

Le Sat, 19 Apr 2014 21:13:58 +0200, Georg Bauhaus  
<rm-host.bauhaus@maps.futureapps.de> a écrit:

> […]
>
> What does funding or not of their project have to do with
> reasons forrejection? And what does funding or not of their
> project have to do with rejection or not? And what does funding
> or not of your project have to do with (reasons for) rejection?
>
> Apple, for example, is known to be secretive about how they will
> finally react, or not react, to bug reports. They are well funded.
>
> Thus it might be an ideal situation when funding means maintenance
> and (responsive) support, but I don't see that funding entails
> the latter two.
>
> […]
>
> Right, and rhetoric is a well established human activity, too.
> Human activities is what may or may not turn the hypothesis that
> Funding = Quality_Assurance into a fact, in each case.

You show it does not always help, especially with some companies. OK.

Since the initial message, I have not suggested it's a mechanical rule,  
just that there are things which may help and others which may make it  
less likely (I suspect we may somewhat agree on this). Offering a  
favourable context, surely can help. If ever you doubt it can help, just  
think about these graduate schools dropping Ada courses because their  
students want to learn something which come with paid job (not unpaid  
volunteer job) opportunities, and this is so even in france, “the country  
of Ada” (just teasing with what's in quotes… I know many countries are  
country of Ada too).

I will stop arguing on this, with this message, which will be the last one  
:-P .

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 12:34 , Georg Bauhaus wrote:

> That Funding = Quality_Assurance is a repeatedly established
> belief in talking about the "software area", so the only thing
> one can honestly assume is that people are going to repeat it.

Look at avionics - where Ada is heavily used for DO-178B level A, B, C 
software.  The required software quality process is a major expense, and 
it is the least inspiring/interesting part of the whole for everyone 
involved (except the SQA people).

But it unquestionably leads to fewer bugs - esp. on changes to software. 
  It does not lead to fast.

So while Funding = Q_A may not be true as an absolute statement, real 
Q_A per requirements[1] requires funding - nobody will do it out of the 
goodness of their hearts or as a hobby or to polish the boss's apple. 
It's tedious stuff.

[1] legal requirement.

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Randy Brukardt]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 2823 bytes --]

"Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message 
news:5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net...
> On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote:
...
>> However you are more likely to get people sticking to good methods, give 
>> time and energy for this, if they get something in return.
>
> Well, that again makes for a hypothesis that is so unspecific
> that it fits the same bill: correlation turned causal based on
> likelihood, ceteris paribus.
> E.g., what are the specifics in terms of work hours, pay, and
> project characteristics? Do we have control-group like evidence?

I can give you a couple of data points:

First, the state of Ada standardization when I was funded to do 
administrative tasks. Before I took over, the ARG had a succession of 
volunteer editors. Toward the end, the only thing produced was meeting 
minutes. No one had organized the suggested changes, or figured out the 
effect on the standard (in some cases, the suggested changes were impossible 
to fit into the standard and we ended up coming up with completely different 
resolutions).

Once I took over, I spent a lot of time on that sort of administrative 
tasks, and in other things that improved the process, like having on-line 
access to version control for documents (prior to my taking over there was 
no version control and on-line access was only to the most recent posted 
version of a document - which often was well behind the current state). This 
work was (and is) not much fun, and I think only someone who was getting 
paid would do it for long. (I'll have been doing it 16 years this fall. 
Wow.)

The second example is the ACATS. Here, I took over directly from another 
paid person (Dan Lehman at the AVO). So I needed to make few changes to the 
basic procedures or approaches; mainly I wrote down a lot of the procedures 
that hadn't been well-documented in the past, and added a few new ones to 
deal with public version control and a finer-grained and more formal 
approach to correcting tests and issuing new tests.

In both cases, I think that having a paid person involved has ensured 
quality that otherwise would not have happened. Working with volunteers is 
often described as herding cats (because one can make little assumptions 
about deadlines or quality of work - even in a group as knowledgeable and 
committed as the ARG - one learns who can be trusted to do work on time, who 
will wait to the last minute, and who probably will never produce anything). 
Someone who can put the pieces together and is empowered to do that is 
critical - and that person has to have a way to eat on jobs that will take 
months.

[Of course, my opinion here may be more than a little biased, so please draw 
your own conclusions.]

                               Randy.

Re: OpenSSL development (Heartbleed)

[G.B.]

On 22.04.14 01:51, Randy Brukardt wrote:
> "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message
> news:5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net...
>> On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote:
> ...
>>> However you are more likely to get people sticking to good methods, give
>>> time and energy for this, if they get something in return.
>>
>> Well, that again makes for a hypothesis that is so unspecific
>> that it fits the same bill: correlation turned causal based on
>> likelihood, ceteris paribus.
>> E.g., what are the specifics in terms of work hours, pay, and
>> project characteristics? Do we have control-group like evidence?
>
> I can give you a couple of data points:
>
> First, the state of Ada standardization[...]


Evidence, indeed!
  Now given ISO/IEC 27000, a family of standards revolving
around security, and Heartbleed, what can anyone do to make
standards effecive? The money paid for the standardization of
security procedures seems not to have affected the source code
of one commercial security "procedure", OpenSSL.
  If Heartbleed is characteristic of paid standardization's
actual outcome, then something is wrong somewhere.
Absurd, in fact.

Re: OpenSSL development (Heartbleed)

[Dmitry A. Kazakov]

On Tue, 22 Apr 2014 17:20:13 +0200, G.B. wrote:

> On 22.04.14 01:51, Randy Brukardt wrote:
>> "Georg Bauhaus" <rm-host.bauhaus@maps.futureapps.de> wrote in message
>> news:5352a585$0$6707$9b4e6d93@newsspool3.arcor-online.net...
>>> On 19/04/14 18:00, Yannick Duchêne (Hibou57) wrote:
>> ...
>>>> However you are more likely to get people sticking to good methods, give
>>>> time and energy for this, if they get something in return.
>>>
>>> Well, that again makes for a hypothesis that is so unspecific
>>> that it fits the same bill: correlation turned causal based on
>>> likelihood, ceteris paribus.
>>> E.g., what are the specifics in terms of work hours, pay, and
>>> project characteristics? Do we have control-group like evidence?
>>
>> I can give you a couple of data points:
>> First, the state of Ada standardization[...]
> 
> Evidence, indeed!
>   Now given ISO/IEC 27000, a family of standards revolving
> around security, and Heartbleed, what can anyone do to make
> standards effecive?

Properly designed standards, maybe? Let me ask a stupid question. What has
a transport level protocol to do with the application level's servers (and
clients)? If it really were a strictly transport level, no implementation
could leak data out of higher levels. Right?

> The money paid for the standardization of
> security procedures seems not to have affected the source code
> of one commercial security "procedure", OpenSSL.
>   If Heartbleed is characteristic of paid standardization's
> actual outcome, then something is wrong somewhere.

You must have software market in first place. Anything which comes free has
no value. There is no market pressure to improve quality and functionality
because there is no liability either monetary or legal. Neither the model
of "intellectual property" nor the free software model is working to reach
these goals, in the sense of an optimization problem.

> Absurd, in fact.

Nothing absurd. If C is selected in the process over Ada, there is a reason
for this. And this reason (which is not lack of {} braces, as people used
to think) influences any SW developing as well. We see the fruits, more to
come...

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OpenSSL development (Heartbleed)

[Simon Clubley]

On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 22 Apr 2014 17:20:13 +0200, G.B. wrote:
>> 
>> Evidence, indeed!
>>   Now given ISO/IEC 27000, a family of standards revolving
>> around security, and Heartbleed, what can anyone do to make
>> standards effecive?
>
> Properly designed standards, maybe? Let me ask a stupid question. What has
> a transport level protocol to do with the application level's servers (and
> clients)? If it really were a strictly transport level, no implementation
> could leak data out of higher levels. Right?
>

No, properly _implemented_ standards are what is required.

Heartbleed came about because a boundary check was missing which allowed
a invalid request to be processed instead of being rejected and, because
of the _implementation_, was allowed access to memory that had nothing to
do with the request.

This was a failure in the implementation of the standard, not a failure
of the standard itself.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: OpenSSL development (Heartbleed)

[Dmitry A. Kazakov]

On Tue, 22 Apr 2014 16:57:28 +0000 (UTC), Simon Clubley wrote:

> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 22 Apr 2014 17:20:13 +0200, G.B. wrote:
>>> 
>>> Evidence, indeed!
>>> Now given ISO/IEC 27000, a family of standards revolving
>>> around security, and Heartbleed, what can anyone do to make
>>> standards effecive?
>>
>> Properly designed standards, maybe? Let me ask a stupid question. What has
>> a transport level protocol to do with the application level's servers (and
>> clients)? If it really were a strictly transport level, no implementation
>> could leak data out of higher levels. Right?
> 
> No, properly _implemented_ standards are what is required.
> 
> Heartbleed came about because a boundary check was missing which allowed
> a invalid request to be processed instead of being rejected and, because
> of the _implementation_, was allowed access to memory that had nothing to
> do with the request.
> 
> This was a failure in the implementation of the standard, not a failure
> of the standard itself.

Boundary checks or not, the transport layer shall have no access to the
server data.

A tightly coupled system is vulnerable. If compromising just one component
opens all gates wide, that is a bad standard and bad design. The effects of
errors and faults must be bounded per design. 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OpenSSL development (Heartbleed)

[Yannick Duchêne (Hibou57)]

Le Tue, 22 Apr 2014 21:53:01 +0200, Dmitry A. Kazakov  
<mailbox@dmitry-kazakov.de> a écrit:
> Boundary checks or not, the transport layer shall have no access to the
> server data.
>
> A tightly coupled system is vulnerable. If compromising just one  
> component
> opens all gates wide, that is a bad standard and bad design. The effects  
> of
> errors and faults must be bounded per design.

There indeed can't be any “Correct By Construction” without this.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: OpenSSL development (Heartbleed)

[Natasha Kerensikova]

On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Tue, 22 Apr 2014 16:57:28 +0000 (UTC), Simon Clubley wrote:
>> No, properly _implemented_ standards are what is required.
>> 
>> Heartbleed came about because a boundary check was missing which allowed
>> a invalid request to be processed instead of being rejected and, because
>> of the _implementation_, was allowed access to memory that had nothing to
>> do with the request.
>> 
>> This was a failure in the implementation of the standard, not a failure
>> of the standard itself.
>
> Boundary checks or not, the transport layer shall have no access to the
> server data.
>
> A tightly coupled system is vulnerable. If compromising just one component
> opens all gates wide, that is a bad standard and bad design. The effects of
> errors and faults must be bounded per design. 

How would you design a transport layer that has no access to whatever is
supposed to be transported?

"Heartbleed" didn't leak any data that ins't legitimataly needed by
OpenSSL (i.e. transported data and/or transport parameters (like keys))

Re: OpenSSL development (Heartbleed)

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote:

> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Tue, 22 Apr 2014 16:57:28 +0000 (UTC), Simon Clubley wrote:
>>> No, properly _implemented_ standards are what is required.
>>> 
>>> Heartbleed came about because a boundary check was missing which allowed
>>> a invalid request to be processed instead of being rejected and, because
>>> of the _implementation_, was allowed access to memory that had nothing to
>>> do with the request.
>>> 
>>> This was a failure in the implementation of the standard, not a failure
>>> of the standard itself.
>>
>> Boundary checks or not, the transport layer shall have no access to the
>> server data.
>>
>> A tightly coupled system is vulnerable. If compromising just one component
>> opens all gates wide, that is a bad standard and bad design. The effects of
>> errors and faults must be bounded per design. 
> 
> How would you design a transport layer that has no access to whatever is
> supposed to be transported?
> 
> "Heartbleed" didn't leak any data that ins't legitimataly needed by
> OpenSSL (i.e. transported data and/or transport parameters (like keys))

I heard it leaked user data, I didn't go into details. I hope user data are
not transported, because otherwise that would be even an greater design
fault.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OpenSSL development (Heartbleed)

[Natasha Kerensikova]

On 2014-04-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote:
>
>> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>> Boundary checks or not, the transport layer shall have no access to the
>>> server data.
>>>
>>> A tightly coupled system is vulnerable. If compromising just one component
>>> opens all gates wide, that is a bad standard and bad design. The effects of
>>> errors and faults must be bounded per design. 
>> 
>> How would you design a transport layer that has no access to whatever is
>> supposed to be transported?
>> 
>> "Heartbleed" didn't leak any data that ins't legitimataly needed by
>> OpenSSL (i.e. transported data and/or transport parameters (like keys))
>
> I heard it leaked user data, I didn't go into details. I hope user data are
> not transported, because otherwise that would be even an greater design
> fault.

Actually it leaked session cookies, that are legitimately part of any
HTTP payload, and login/passwords, that are legitimately part of the
HTTP payload of the authentication request.

At that point the remaining of the user data is considered compromised
as well, because of the possibility of session/credential hijacking,
but that's only an indirect result of heartbleed, and requires a
separate attack.

Re: OpenSSL development (Heartbleed)

[Dmitry A. Kazakov]

On Wed, 23 Apr 2014 07:40:44 +0000 (UTC), Natasha Kerensikova wrote:

> On 2014-04-23, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>> On Wed, 23 Apr 2014 05:38:21 +0000 (UTC), Natasha Kerensikova wrote:
>>
>>> On 2014-04-22, Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>>>> Boundary checks or not, the transport layer shall have no access to the
>>>> server data.
>>>>
>>>> A tightly coupled system is vulnerable. If compromising just one component
>>>> opens all gates wide, that is a bad standard and bad design. The effects of
>>>> errors and faults must be bounded per design. 
>>> 
>>> How would you design a transport layer that has no access to whatever is
>>> supposed to be transported?
>>> 
>>> "Heartbleed" didn't leak any data that ins't legitimataly needed by
>>> OpenSSL (i.e. transported data and/or transport parameters (like keys))
>>
>> I heard it leaked user data, I didn't go into details. I hope user data are
>> not transported, because otherwise that would be even an greater design
>> fault.
> 
> Actually it leaked session cookies, that are legitimately part of any
> HTTP payload, and login/passwords, that are legitimately part of the
> HTTP payload of the authentication request.
> 
> At that point the remaining of the user data is considered compromised
> as well, because of the possibility of session/credential hijacking,
> but that's only an indirect result of heartbleed, and requires a
> separate attack.

To my limited knowledge it sent some dumps of the server's memory. Again, a
silly Boy Scout's question, how a *transport* layer could even come to
this?

To me this looks a protocol layer encapsulation fault. (Not a big wonder
considering the huge mess web protocols represent.)

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 23/04/14 10:04, Dmitry A. Kazakov wrote:
> To my limited knowledge it sent some dumps of the server's memory. Again, a
> silly Boy Scout's question, how a*transport*  layer could even come to
> this?
>
> To me this looks a protocol layer encapsulation fault. (Not a big wonder
> considering the huge mess web protocols represent.)

Some have found it suspicious that a "ping" like thing
would transport anything, making this appear to be a backdoor.
See fefe's blog, for example (German, Apr 9).

"(...). Aus meiner Sicht riecht das wie eine Backdoor, es schmeckt
wie eine Backdoor, es hat die Konsistenz einer Backdoor,
und es sieht aus wie eine Backdoor".

"(...). From my point of view it smells like a backdoor, it tastes
like a backdoor, it has the texture of a backdoor,
and it looks like a backdoor".


This comment has been address by the OpenSSL author,
a little later (ibd.).

Re: OpenSSL development (Heartbleed)

[Egil H H]

On Wednesday, April 23, 2014 9:30:08 AM UTC+2, Dmitry A. Kazakov wrote:
> 
> I heard it leaked user data, I didn't go into details. I hope user data are
> 
> not transported, because otherwise that would be even an greater design
> 
> fault.

Here's a fairly good explanation:
http://xkcd.com/1354/

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 23/04/14 09:30, Dmitry A. Kazakov wrote:

>>> Boundary checks or not, the transport layer shall have no access to the
>>> server data.
>>>
>>> A tightly coupled system is vulnerable. If compromising just one component
>>> opens all gates wide, that is a bad standard and bad design. The effects of
>>> errors and faults must be bounded per design.
>>
>> How would you design a transport layer that has no access to whatever is
>> supposed to be transported?
>>
>> "Heartbleed" didn't leak any data that ins't legitimataly needed by
>> OpenSSL (i.e. transported data and/or transport parameters (like keys))
>
> I heard it leaked user data, I didn't go into details. I hope user data are
> not transported, because otherwise that would be even an greater design
> fault.

They are not, by design, transported. I think the issue
boiled down to using some int variable `p' as an offset without
checking bounds. OpenSSL sometimes uses its own malloc,
for historical reasons. So, perhaps this approximates.

At least GNAT warns, no matter what. What do other compiler
diagnose?

with System.Storage_Elements;  use System.Storage_Elements;
with Ada.Integer_Text_IO;

procedure Leak is
    type A is array (Integer range <>) of Storage_Element;
    type A_P is access all A;

    Pool : A (1 .. 123_456);
    for Pool'Address use To_Address (16#100_000#);
    Current_Offset : Storage_Offset := 0;

    function Our_Own_Malloc (Size : Natural) return A_P is
       Result : A_P;
       for Result'Address use Pool'Address + Current_Offset;
    begin
       Current_Offset := Current_Offset + Storage_Offset (Size);
       return Result;
    end Our_Own_Malloc;

    function Something (P : Integer) return A is
       Result : A_P;
    begin
       Result := Our_Own_Malloc (P);
       return Result.all;
    end Something;

    use Ada.Integer_Text_IO;
    I : Integer;
begin
    Get(I);
    declare
       Y : A := Something (I);
    begin
       null;
    end;
end Leak;

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 11:36 , Georg Bauhaus wrote:

> In between, reports of booing, bemoaning, and demanding; journalist
> tries to establish a scape goat (OpenSSL users don't fund!).
> No proof, no clear indication of causation, but alluding in style.
> By saying that OpenSSL is not a well funded project, she obviously
> tries to imply that this is (a) true in effect, and (b) that funding
> prevents bugs. (a): most of OpenSSL does exist only after work
> of payed employees. (b): See bugs discovered at the same time in well
> funded MS Word and MS Outlook projects, of similar reach.

And how does that make you feel?

Please see this as well:

http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects/?action=click&contentCollection=Technology&module=RelatedCoverage&region=Marginalia&pgtype=article

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 18:06, Alan Browne wrote:
> On 2014.04.19, 11:36 , Georg Bauhaus wrote:
>
>> In between, reports of booing, bemoaning, and demanding; journalist
>> tries to establish a scape goat (OpenSSL users don't fund!).
>> No proof, no clear indication of causation, but alluding in style.
>> By saying that OpenSSL is not a well funded project, she obviously
>> tries to imply that this is (a) true in effect, and (b) that funding
>> prevents bugs. (a): most of OpenSSL does exist only after work
>> of payed employees. (b): See bugs discovered at the same time in well
>> funded MS Word and MS Outlook projects, of similar reach.
>
> And how does that make you feel?

Depends. Sometimes I feel that industry should rid itself of
its dependence on so few suppliers of an ever increasing number
of "industry standards",  open source or not, and on
PR style people. Some things are just too important for healthy
living, both at work and at home. So important that these things
should be exempt from being nothing but a business opportunity.

> Please see this as well:
>
> http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects/?action=click&contentCollection=Technology&module=RelatedCoverage&region=Marginalia&pgtype=article

Same thing...

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 18:42, Georg Bauhaus wrote:
> exempt from being nothing but a business opportunity.

Sorry, "barred", "excluded", or "saved" probably are better
words. I don't have software to help me with English...

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 12:42 , Georg Bauhaus wrote:
> On 19/04/14 18:06, Alan Browne wrote:
>> On 2014.04.19, 11:36 , Georg Bauhaus wrote:
>>
>>> In between, reports of booing, bemoaning, and demanding; journalist
>>> tries to establish a scape goat (OpenSSL users don't fund!).
>>> No proof, no clear indication of causation, but alluding in style.
>>> By saying that OpenSSL is not a well funded project, she obviously
>>> tries to imply that this is (a) true in effect, and (b) that funding
>>> prevents bugs. (a): most of OpenSSL does exist only after work
>>> of payed employees. (b): See bugs discovered at the same time in well
>>> funded MS Word and MS Outlook projects, of similar reach.
>>
>> And how does that make you feel?
>
> Depends. Sometimes I feel that industry should rid itself of
> its dependence on so few suppliers of an ever increasing number
> of "industry standards",  open source or not, and on
> PR style people. Some things are just too important for healthy
> living, both at work and at home. So important that these things
> should be exempt from being nothing but a business opportunity.

I think so too.

IMO interchange on intra/internets should be formal standards based. 
Those standards should be done in the same manner as aerospace and 
defense s/w.  It's okay if a pool of companies create the company that 
does so - but the sole source of release should be that company.

>> Please see this as well:
>>
>> http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects/?action=click&contentCollection=Technology&module=RelatedCoverage&region=Marginalia&pgtype=article
>>
>
> Same thing...

No.  Where OpenSSL is underfunded and has a population of maybe 4 
programmers dedicated to it (the guy who created the bug not being one 
of the 4) released an important security breach upon the masses;

Contrast with OpenSourced Linux which has a well (corporate) funded 
organization and has a lot more eyeballs on the code and hasn't (Linux 
itself) suffered any major or embarrassing problems.

That was the point of the article.

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 21:12, Alan Browne wrote:
>
> No.  Where OpenSSL is underfunded and has a population of maybe 4 programmers dedicated to it (the guy who created the bug not being one of the 4) released an important security breach upon the masses;
>
> Contrast with OpenSourced Linux which has a well (corporate) funded organization and has a lot more eyeballs on the code and hasn't (Linux itself) suffered any major or embarrassing problems.

A comparison of one bug in one library to bugs in the amount of
software that is "Enterprise Linux"  does not seem balanced
enough.
      Also, insofar as OpenSSL is well associated with
open source Linux, it is likely that fixing Heartbleed-like
bugs will be covered by {Redhat, ...} support. This adds to
an argument that there actually is funding for OpenSSL etc.,
or, conversely, that there is never enough funding for all the
software to be bug free.
  At least, that seems to be the argument of the articles:
that funding and enterprise support is supposed to achieve
so high a quality of software that it would have prevented
Heartbleed etc.


OTOH, and bringing this back to Ada, the CVE sites state quite
openly that most of the issues have to do with int, malloc,
computed pointers, and assumptions that are not reflected in all
of these (overflow, say).
  If it is possible to make programmers use an Ada style fundamental
type system instead, thus also better arrays and fewer pointers,
this change would naturally reflect more of the assumptions. The
conclusion can only be that this change makes the software so written
as good as the assumptions. According to McCormick's findings,
that's not nothing. The fundamentals do matter.

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 16:20 , Georg Bauhaus wrote:
> On 19/04/14 21:12, Alan Browne wrote:
>>
>> No.  Where OpenSSL is underfunded and has a population of maybe 4
>> programmers dedicated to it (the guy who created the bug not being one
>> of the 4) released an important security breach upon the masses;
>>
>> Contrast with OpenSourced Linux which has a well (corporate) funded
>> organization and has a lot more eyeballs on the code and hasn't (Linux
>> itself) suffered any major or embarrassing problems.
>
> A comparison of one bug in one library to bugs in the amount of
> software that is "Enterprise Linux"  does not seem balanced
> enough.

I was simply refuting that the 2nd article was the "same thing" as the 
first.  The 2nd pointed out two cases.


>       Also, insofar as OpenSSL is well associated with
> open source Linux, it is likely that fixing Heartbleed-like
> bugs will be covered by {Redhat, ...} support. This adds to
> an argument that there actually is funding for OpenSSL etc.,
> or, conversely, that there is never enough funding for all the
> software to be bug free.

OpenSSL appears from these reports to be "out on the limb" away from the 
more richly supported trunk.

>   At least, that seems to be the argument of the articles:
> that funding and enterprise support is supposed to achieve
> so high a quality of software that it would have prevented
> Heartbleed etc.

Reduced the likelihood, anyway.

Truly, it would be better if requirements were set and then the s/w 
designed, nay, engineered, to meet the requirements.  One day perhaps.

But until someone (an entity) seizes control of the release process, 
there will be no engineering to a level that would prevent these sorts 
of problems.

This is not the last.

> OTOH, and bringing this back to Ada, the CVE sites state quite
> openly that most of the issues have to do with int, malloc,
> computed pointers, and assumptions that are not reflected in all
> of these (overflow, say).

QUOTE
Theo de Raadt, founder and leader of the OpenBSD and OpenSSH projects, 
has criticized the OpenSSL developers for writing their own memory 
management routines and thereby circumventing OpenBSD C standard library 
exploit countermeasures, saying "OpenSSL is not developed by a 
responsible team."
ENDQUOTE

Ironic that one Open team leader is criticizing another <g>

But, he may be right.

Would he subject his teams to a more rigorous process?  To Ada?


>   If it is possible to make programmers use an Ada style fundamental
> type system instead, thus also better arrays and fewer pointers,
> this change would naturally reflect more of the assumptions. The
> conclusion can only be that this change makes the software so written
> as good as the assumptions. According to McCormick's findings,
> that's not nothing. The fundamentals do matter.

Of course they do.

Now, do you really think the industry will change to something more 
formalized and requirements driven?  Use Ada as a fundamental building 
block of it?

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

[OT] OpenBSD, was: Re: OpenSSL development (Heartbleed)

[Simon Clubley]

On 2014-04-19, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
> On 2014.04.19, 16:20 , Georg Bauhaus wrote:
>> OTOH, and bringing this back to Ada, the CVE sites state quite
>> openly that most of the issues have to do with int, malloc,
>> computed pointers, and assumptions that are not reflected in all
>> of these (overflow, say).
>
> QUOTE
> Theo de Raadt, founder and leader of the OpenBSD and OpenSSH projects, 
> has criticized the OpenSSL developers for writing their own memory 
> management routines and thereby circumventing OpenBSD C standard library 
> exploit countermeasures, saying "OpenSSL is not developed by a 
> responsible team."
> ENDQUOTE
>
> Ironic that one Open team leader is criticizing another <g>
>

Not if you know what Theo is like. :-)

> But, he may be right.
>
> Would he subject his teams to a more rigorous process?  To Ada?
>

Yes to the first; unknown on the second.

OpenBSD has a reputation as a reasonably secure (by Unix standards)
operating system precisely due to the auditing the OpenBSD team
carries out.

Note that this is a reputation based assessment; I don't have much
direct experience with OpenBSD.

Some reading you may find of interest:

	http://www.openbsd.org/security.html

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

Re: [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 17:10 , Simon Clubley wrote:
> On 2014-04-19, Alan Browne <alan.browne@FreelunchVideotron.ca> wrote:
>> On 2014.04.19, 16:20 , Georg Bauhaus wrote:
>>> OTOH, and bringing this back to Ada, the CVE sites state quite
>>> openly that most of the issues have to do with int, malloc,
>>> computed pointers, and assumptions that are not reflected in all
>>> of these (overflow, say).
>>
>> QUOTE
>> Theo de Raadt, founder and leader of the OpenBSD and OpenSSH projects,
>> has criticized the OpenSSL developers for writing their own memory
>> management routines and thereby circumventing OpenBSD C standard library
>> exploit countermeasures, saying "OpenSSL is not developed by a
>> responsible team."
>> ENDQUOTE
>>
>> Ironic that one Open team leader is criticizing another <g>
>>
>
> Not if you know what Theo is like. :-)
>
>> But, he may be right.
>>
>> Would he subject his teams to a more rigorous process?  To Ada?
>>
>
> Yes to the first; unknown on the second.
>
> OpenBSD has a reputation as a reasonably secure (by Unix standards)
> operating system precisely due to the auditing the OpenBSD team
> carries out.
>
> Note that this is a reputation based assessment; I don't have much
> direct experience with OpenBSD.
>
> Some reading you may find of interest:
>
> 	http://www.openbsd.org/security.html

Seen it before.  I don't really believe their philosophy is forward 
thinking.  (Audit things to death and you will find bugs and improve the 
system) is not what the world should be doing.  It should be designing 
and engineering things so that they are not likely to have security 
holes and bugs in the first place.

In effect they are confirming that C is a terrible language to write 
anything requiring security and so it needs never ending vigilance.

So what they are doing is right for anything written in Cieve.

(Get it? C + Sieve = Cieve).

Not to say Ada results in bullet proof - but if used as intended there 
would be very few security holes of the many sorts that seem to pop up.


-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed)

[Nasser M. Abbasi]

On 4/19/2014 4:53 PM, Alan Browne wrote:

>
> In effect they are confirming that C is a terrible language to write
> anything requiring security and so it needs never ending vigilance.
>

Sure. When the language is weakly typed, more manual
effort in terms of more code eye balling, more debugging,
more testing and more code inspection is needed relative
to using a strongly typed language. Instead of getting
help from the language/compiler in finding many errors
early on, human time and effort is used instead to
compensate.

This is nothing new ;)

> Not to say Ada results in bullet proof - but if used as intended there
> would be very few security holes of the many sorts that seem to pop up.
>

--Nasser
  

Re: [OT] OpenBSD, was: Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 18:15 , Nasser M. Abbasi wrote:
> On 4/19/2014 4:53 PM, Alan Browne wrote:
>
>>
>> In effect they are confirming that C is a terrible language to write
>> anything requiring security and so it needs never ending vigilance.
>>
>
> Sure. When the language is weakly typed, more manual
> effort in terms of more code eye balling, more debugging,
> more testing and more code inspection is needed relative
> to using a strongly typed language. Instead of getting
> help from the language/compiler in finding many errors
> early on, human time and effort is used instead to
> compensate.
>
> This is nothing new ;)

I know - this was all reflection on the Pot (Mr. OpenBSD) calling the 
kettle (the OpenSSL four) black.

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 22:53, Alan Browne wrote:
> Now, do you really think the industry will change to something more formalized and requirements driven?  Use Ada as a fundamental building block of it?

Where C (or no S/E) is being used, directly, or indirectly by using
libraries written in C, the industry seems stuck in a loop of at least

(1) self-referential confirmation,
(2) insufficient irritation caused by C (or lack of S/E), and
(3) sufficient competitive equality.

One faint hope that I currently maintain is that some BigCo, not the
industry, might produce a change to using C. The change might be like
the ones just now performed in the case of hugely popular languages:
PHP might become Hack everywhere because Facebook has produced Hack by
"enhancing" PHP; Microsoft has already produced C#, VB#, etc., by
"enhancing" each of the respective assimilated languages; Apple's
"enhanced" C in Objective-C is already far above what the C standard
requires of an implementation if seen through the lenses of their
static analyzer. Google makes their talented staff spend some "free"
time on "enhancing" the special qualities of JavaScript.

And the results are all free, working, and ubiquitous.

Suppose something similar happens in the C world.

Apparently, all it takes is hiring a few smart compiler writers
and have them "enhance" the popular language C in such a way
that C programmers can simply enjoy the new features whenever they wish.
(Intel?, Freescale?)


To elaborate, for the sake of completeness only, the claims of
(1), (2), and (3),

(1) As long as the company does not go bankrupt, and the project's
goal was not entirely missed, choosing C is justified. So, project
management can confirm that it was the right choice, obviously.
So does everyone.

(2) It is well known that: "Software has bugs." "Tom De Marco says
that the effect of language is <= 5%, so why bother." Studies
comparing the effects of languages or methods are rare. They seem to
be interpreted by shooting from the hip or in other surprising
ways[*]. If effects of bugs can be handled by customer care, then C's
features may be seen as causing costly bugs, however the pressure
isn't high enough.  Internally, excuses are at hand. (Not the least
of which is "A..... 5!")

(3) By simple arithmetic, if all the competition is using C (or no S/E),
everyone incurs the same cost, yet there is return on investment.
Consequently, then, using C (or no S/E) does not cause any
relative economic disadvantage. Whereas investing in different
technology is associated with risk, education, and other cost factors.
Who is going to start an initiative, then, and why?

__
[*] One anecdote I heard was about two teams, one using C++, the
other using SPARK, programming to the same specification for one
year. Either team could use a simulator. The teams were tasked with
producing programs for driving a test device. The C++ team
debugged their software into existence, frequently testing in the
simulator. The SPARK team first found a bug in the specification,
then went on to prove software into existence, hardly if ever using
the simulator. Finally, the C++ team had implemented 80% of the features.
Some bugs were found in the final product. The SPARK team had
implemented 100% of the features (close to closing time). No bugs
were found in the final product.
   Interpretation of the result: Use of the approach of C++ is
preferable since project management then does not suffer a heart
attack because they have no facts to report while the project
is underway.

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.20, 04:17 , Georg Bauhaus wrote:
> On 19/04/14 22:53, Alan Browne wrote:
>> Now, do you really think the industry will change to something more
>> formalized and requirements driven?  Use Ada as a fundamental building
>> block of it?
>
> Where C (or no S/E) is being used, directly, or indirectly by using
> libraries written in C, the industry seems stuck in a loop of at least
>
> (1) self-referential confirmation,
> (2) insufficient irritation caused by C (or lack of S/E), and
> (3) sufficient competitive equality.
>
> One faint hope that I currently maintain is that some BigCo, not the
> industry, might produce a change to using C. The change might be like
> the ones just now performed in the case of hugely popular languages:
> PHP might become Hack everywhere because Facebook has produced Hack by
> "enhancing" PHP; Microsoft has already produced C#, VB#, etc., by
> "enhancing" each of the respective assimilated languages; Apple's
> "enhanced" C in Objective-C is already far above what the C standard
> requires of an implementation if seen through the lenses of their
> static analyzer. Google makes their talented staff spend some "free"
> time on "enhancing" the special qualities of JavaScript.
>
> And the results are all free, working, and ubiquitous.

Is it possible to identify a particular client side layer item (app, 
transport, internet or link) that is relatively small that could be 
designed and written in Ada and that could "drop in" as a replacement?

Obviously it would have to hook up and down in the system and 'look' for 
all intents and purposes like its C predecessor?

That would be a good proving ground for an Ada approach.  How to link 
them to the "C" code above and below ....
  __
> [*] One anecdote I heard was about two teams, one using C++, the
> other using SPARK, programming to the same specification for one
> year. Either team could use a simulator. The teams were tasked with
> producing programs for driving a test device. The C++ team
> debugged their software into existence, frequently testing in the
> simulator. The SPARK team first found a bug in the specification,
> then went on to prove software into existence, hardly if ever using
> the simulator. Finally, the C++ team had implemented 80% of the features.
> Some bugs were found in the final product. The SPARK team had
> implemented 100% of the features (close to closing time). No bugs
> were found in the final product.
>    Interpretation of the result: Use of the approach of C++ is
> preferable since project management then does not suffer a heart
> attack because they have no facts to report while the project
> is underway.

Amusing.  But there's nothing to prevent progress reporting on 
non-spiral development - the gates just have to be defined correctly.

Reminds me of a programmer assigned, alone, to write the software for an 
avionics system.  He chose assembler on a microprocessor for which he 
had no experience.  (We were not yet at the "ban assembler" point).

He designed (eg: wrote the documentation to full draft).  He followed 
the new programming style guidelines from our SQA.  He coded (hand 
written - believe it or not).  When his code was 100% written to spec, 
he and a word processing girl began entering the source code (she worked 
about 10x faster than him).

Then, with 100% of the code entered, he began assembling the files.

Then, through generated errors and in examining the machine code, he 
discovered that his understanding of the register set and memory model 
of the 8086 were completely wrong.

So.  He went back to his desk and began re-coding the entire thing in 
assembler again.  Hand written.  (But this time handed them off to the 
WP lady to enter the next day).  The re-coding didn't take very long 
since the overall design did not change at all.  (This is really the 
important part).

He assembled.  He corrected.  He loaded the code onto the engineering 
prototype h/w and found a few bugs.

 From the first loadable executable to an on-spec bug free system took 
less than a working week (he worked 10 to 6.  No more.  No less.  Ever). 
  He didn't use the nice ICE system we had.

And ahead of schedule.

This rare discipline in programming I've never seen since.

The funny thing was he was a mathematician and didn't like computers 
much - but had found a job as a programmer...

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[G.B.]

On 20.04.14 18:49, Alan Browne wrote:
> Is it possible to identify a particular client side layer item (app,
> transport, internet or link) that is relatively small that could be
> designed and written in Ada and that could "drop in" as a replacement?
>
> Obviously it would have to hook up and down in the system and 'look' for
> all intents and purposes like its C predecessor?


One such example is the Ironsides DNS server, I think,

http://ironsides.martincarlisle.com/

I guess the program may well be a target for appraisal.
In any case, since this can replace one layer item,
it is proof of concept.

Would people at Cisco take note of the possibilities of "language
advantages", and S/E? (If they are "allowed" to make their devices
more secure, which I do not know.)

http://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20140409-heartbleed

Another hint is found in the use of Ada when cracking the Lorenz
code. According to the winner, the cryptographic algorithms were
expressed more clearly, and, quoting, *concisely*!

http://www.drdobbs.com/parallel/tunny-colossus-and-ada-keeping-an-open/207800151

Re: OpenSSL development (Heartbleed)

[Yannick Duchêne (Hibou57)]

Le Sat, 19 Apr 2014 16:31:39 +0200, Alan Browne  
<alan.browne@freelunchvideotron.ca> a écrit:

>
> Good article in the NYT:
>
> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business
>

I surely gonna be blamed for saying this, however what can be noted here,  
is that a [political] movement which is always shouting at commercial  
companies is at the same time always expecting funds from them. How can  
you one be serious expecting the end of something while organizing a  
dependency on this thing? Also, and that's not a surprise, nothing is  
expected from “ordinary users”, who do benefit as much from  
unsupported/unpaid jobs as commercial companies do.

People should stop believing in miracles and magic formulas and become  
responsible (all the people, not just the commercial companies as a well  
know political movement suggest).

There is nothing one can get for strictly nothing (for a little fee may be  
practical, but not for strictly nothing), even with software (which is not  
just a matter of copying files as a well known movement wants to make  
people believe). I hope someone will be able to bring back basic economic  
principles in this area some day in the future.


-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 11:47 , Yannick Duchêne (Hibou57) wrote:
> Le Sat, 19 Apr 2014 16:31:39 +0200, Alan Browne
> <alan.browne@freelunchvideotron.ca> a écrit:
>
>>
>> Good article in the NYT:
>>
>> http://www.nytimes.com/2014/04/19/technology/heartbleed-highlights-a-contradiction-in-the-web.html?ref=business
>>
>>
>
> I surely gonna be blamed for saying this, however what can be noted
> here, is that a [political] movement which is always shouting at
> commercial companies is at the same time always expecting funds from
> them. How can you one be serious expecting the end of something while
> organizing a dependency on this thing? Also, and that's not a surprise,
> nothing is expected from “ordinary users”, who do benefit as much from
> unsupported/unpaid jobs as commercial companies do.
>
> People should stop believing in miracles and magic formulas and become
> responsible (all the people, not just the commercial companies as a well
> know political movement suggest).
>
> There is nothing one can get for strictly nothing (for a little fee may
> be practical, but not for strictly nothing), even with software (which
> is not just a matter of copying files as a well known movement wants to
> make people believe). I hope someone will be able to bring back basic
> economic principles in this area some day in the future.


Another article in the NYT contrasts SSL to Linux.  It points out that 
the Linux foundation (of which St. Linus is a key employee) gets over 
$6M / year in corporate funding (s. Wikipedia).

http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects

Linux is a pretty reliable and solid OS.  Having "one Master" (Torvalds 
seems to still be the kernel merge master) and funding obviously helps.

https://en.wikipedia.org/wiki/Linux_Foundation#Members & Funding


-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 18:21, Alan Browne wrote:
> Linux is a pretty reliable and solid OS.  Having "one Master" (Torvalds seems to still be the kernel merge master) and funding obviously helps.

What is the evidence of "obvious" here? I'm not denying
that something may be the case. However, using "obvious" is either
political rhetoric, or else one of the lesser habits of mathematical
style:

Some masters drive things against walls. Costly. Others succeed in
getting really good things done. Why is that? What is "obvious" here?


(You may have heard of the continuing failures to build BER airport.
In spite of good ideas, good engineers, etc., something is wrong
somewhere. Obvious?)

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 12:46 , Georg Bauhaus wrote:
> On 19/04/14 18:21, Alan Browne wrote:
>> Linux is a pretty reliable and solid OS.  Having "one Master"
>> (Torvalds seems to still be the kernel merge master) and funding
>> obviously helps.
>
> What is the evidence of "obvious" here? I'm not denying
> that something may be the case. However, using "obvious" is either
> political rhetoric, or else one of the lesser habits of mathematical
> style:
>
> Some masters drive things against walls. Costly. Others succeed in
> getting really good things done. Why is that? What is "obvious" here?
>
>
> (You may have heard of the continuing failures to build BER airport.
> In spite of good ideas, good engineers, etc., something is wrong
> somewhere. Obvious?)

I'm sorry if I'm not up to your strict standard of language use - what I 
wanted to point out is that Linux (kernel) has many maintainers but a 
narrow choke point to release in the form of Mr. Torvalds (and/or his 
team).

That - for the time being - helps drive reliability.  It does not imply 
that that model will work for all endeavours, or that it can be copied 
as is.  What it does imply is that a single-point-of-care-and-release 
would make for the possibility of stricter control over what can be 
released - following appropriate change control, requirements 
definition, testing and so on.

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Georg Bauhaus]

On 19/04/14 21:22, Alan Browne wrote:
> What it does imply is that a single-point-of-care-and-release would make for the possibility of stricter control over what can be released - following appropriate change control, requirements definition, testing and so on.

IOW, the bazaar may need a cathedral. Agreed.

(Is anyone up for throwing the dialectic synthesis of these
topoi into the press as a development of Raymond's idea?)

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 16:33 , Georg Bauhaus wrote:
> On 19/04/14 21:22, Alan Browne wrote:
>> What it does imply is that a single-point-of-care-and-release would
>> make for the possibility of stricter control over what can be released
>> - following appropriate change control, requirements definition,
>> testing and so on.
>
> IOW, the bazaar may need a cathedral. Agreed.

Yes.  I've avoided that comparison but it's sort of right.  OTOH, his 
"19 lessons" do not fit well into disciplined, deliberate, software 
engineering processes for infrastructure (internet).

> (Is anyone up for throwing the dialectic synthesis of these
> topoi into the press as a development of Raymond's idea?)

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07

Re: OpenSSL development (Heartbleed)

[Yannick Duchêne (Hibou57)]

Le Sat, 19 Apr 2014 18:21:32 +0200, Alan Browne  
<alan.browne@freelunchvideotron.ca> a écrit:
>
> Another article in the NYT contrasts SSL to Linux.  It points out that  
> the Linux foundation (of which St. Linus is a key employee) gets over  
> $6M / year in corporate funding (s. Wikipedia).
>
> http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects
>

I've seen this interesting article already after you posted it before.  
This is still not OK in many ways (I have reproaches to both Torvald and  
Linux for desktop), but I won't tell more (that's an Ada newsgroup here  
after all, not a general software or software economy newsgroup).

Thanks for sharing anyway :-P .

-- 
“Syntactic sugar causes cancer of the semi-colons.” [1]
“Structured Programming supports the law of the excluded muddle.” [1]
[1]: Epigrams on Programming — Alan J. — P. Yale University

Re: OpenSSL development (Heartbleed)

[Alan Browne]

On 2014.04.19, 12:50 , Yannick Duchêne (Hibou57) wrote:
> Le Sat, 19 Apr 2014 18:21:32 +0200, Alan Browne
> <alan.browne@freelunchvideotron.ca> a écrit:
>>
>> Another article in the NYT contrasts SSL to Linux.  It points out that
>> the Linux foundation (of which St. Linus is a key employee) gets over
>> $6M / year in corporate funding (s. Wikipedia).
>>
>> http://bits.blogs.nytimes.com/2014/04/18/openssl-and-linux-a-tale-of-two-open-source-projects
>>
>>
>
> I've seen this interesting article already after you posted it before.
> This is still not OK in many ways (I have reproaches to both Torvald and
> Linux for desktop), but I won't tell more (that's an Ada newsgroup here
> after all, not a general software or software economy newsgroup).

Linux is a GREAT OS.
Linux sucks for desktop users.

Ça va comme ça?

>
> Thanks for sharing anyway :-P .

Of course.

-- 
"Big data can reduce anything to a single number,
  but you shouldn’t be fooled by the appearance of exactitude."
      -Gary Marcus and Ernest Davis, NYT, 2014.04.07