[SystemSafety] FW: OpenSSL Bug

[Martin Pugh]

However, I don’t know how you would encourage the open source community to adopt such practices.

 

MRP

 

From: Martin Pugh [mailto:martin.pugh at blueyonder.co.uk] 
Sent: 14 April 2014 22:06
To: 'Peter Bernard Ladkin'
Subject: RE: [SystemSafety] OpenSSL Bug

 

The way this error would have been caught is requirements traceability 

down to code level with specific test cases for each requirement

and independent review/scrutiny.

(As described in DO-178B)

This is technology independent although there are tools to help.

 

Martin Pugh

 

From: Peter Bernard Ladkin [mailto:ladkin at rvs.uni-bielefeld.de] 
Sent: 14 April 2014 21:57
To: Martin Pugh
Cc: <systemsafety at TechFak.Uni-Bielefeld.DE <mailto:systemsafety at TechFak.Uni-Bielefeld.DE> >
Subject: Re: [SystemSafety] OpenSSL Bug

 

 


On 14 Apr 2014, at 22:43, "Martin Pugh" <martin.pugh at blueyonder.co.uk <mailto:martin.pugh at blueyonder.co.uk> > wrote:

 

Comparing OpenSSL rev 1.0.1 f and g (fixed) .........

This corrects an implementation error which didn't meet the requirement i.e. RFC6520 sec 4 as the comment says.

 

So you are saying that a specific requirement was unfulfilled by Rev 1.0.1f.

 

All this argument about languages, type checking, array bounds checking etc is irrelevant in this particular instance.

 

How does that follow?

 

If the requirement would automatically have been fulfilled if a particular technology had been used, how can it follow that that technology is "irrelevant in this particular case"?

 

I take my hat off to the open source community for their efforts.

 

Me too in general. But it's a problem that we can't seem to persuade them to use established high-reliability programming methods for code for which high reliability is essential.

 

PBL

 

Prof. Peter Bernard Ladkin, University of Bielefeld and Causalis Limited



---
This email is free from viruses and malware because avast! Antivirus protection is active.
http://www.avast.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.techfak.uni-bielefeld.de/mailman/private/systemsafety/attachments/20140414/388d9d26/attachment-0001.html>