[trustable-software] What is Trustable About ?

Paul Sherwood paul.sherwood at codethink.co.uk
Tue Apr 2 13:48:52 BST 2019


Hi Dan,

I very much appreciate the points you've raised in this and other recent 
emails. Please see my comments on this one below...

On 2019-03-31 12:51, Dan Shearer wrote:
> On Sun, 31 Mar 2019 at 11:26, <trustable at panic.fluff.org> wrote:
> 
>> As i've raised several times on this list, it is my view that 
>> trustable is
>> about 'harm' and this exists large number of realms, and not just
>> personal, but corporate and societal. My particularly concern is that
>> complexity cannot and is not to be avoided, but by its nature often 
>> brings
>> with it difficulties in understanding the implications and as seen by
>> behaviour of complex systems their societal impact in the end harms
>> society and so the individual.
> 
> Complexity, cascade failures and the like are very important. But I
> also like to use specific examples of code, and here's one. Because
> otherwise theoretical notions of Good Software end up dancing on the
> head of a pin.

Agreed. "Which is better, theory or practice? In theory, theory, but in 
practice, practice."

> SQLite considered the most widely used database in the world. The
> SQLite code is found in all sorts of surprising places because it is
> quick, simple, free and also often found in libraries that the user
> may not even be aware of. It is very easy to demonstrate that SQLite
> is corruptible, indeed it is corruptible by design according to the
> documentation: https://www.sqlite.org/isolation.html , and that is
> without its many other well-known limitations. Therefore for many
> purposes SQLite cannot be regarded as trustable, whatever the
> definition. I will not try to get a list of safety critical places
> SQLite is used, as the most popular database by a long shot, the
> answer is "all kinds of embedded and IoT devices and desktop software
> besides".
> 
> Could Trustable move the needle on this sort situation?

It may be a barely visible, but my own needle has already moved since I 
wrote the original call to action.

In general I was worrying (and continue to worry) about "safety" and 
"security". Through the discussions here and elsewhere I've come to 
conclude that these topics are not relevant for software on its own. 
They can only be considered meaningfully in the context of a specific 
system/service. This has led me into arguments with (amongst others) 
"safety professionals" who cite established guidance for supposed 
creation of "safe software" independent of any context, which appears to 
me to be a pointless exercise.

I'm hoping that we (humanity in general, not just Trustable) can move 
the needle towards establishing clear norms around the need for

1) system-level thinking about risks/hazards
2) supported by architecture/design to demonstrate how these are to be 
mitigated
3) leading to clear expectations on software behaviours and properties.

Since the spread of the cult of "Agile", I believe we've seen a dramatic 
decrease in the level of systems thinking relating to typical software, 
hence the IoT and the other use-cases you refer to are typically 
deployed without credible risk analysis, let alone consideration of 
mitigations.

For your specific example, I expect that we can agree that SQLite is 
excellent software which can be trusted to perform reliably in a wide 
range of scenarios. I think that gap/issue in this specific case is not 
about the software - it's about ensuring an architectural approach to 
avoid hazards due to SQLIte's 'corruptible' design. However I do believe 
our community can help to address it (even if only by triggering smarter 
folks in other communities to run with the ball).

br
Paul





More information about the trustable-software mailing list