[trustable-software] RFC: Software to be Trustable

Malcolm evans malcolm.evans at codethink.co.uk
Fri Feb 3 17:30:26 UTC 2017



Malcolm Evans
CEO, The UK Manufacturing Accelerator
The Shed, Chester Street
Manchester M1 5GD
07939 033225
www.ukaccelerator.co.uk

Made Great, in Britain


> On 3 Feb 2017, at 16:05, Paul Sherwood <paul.sherwood at codethink.co.uk> wrote:
> 
> Hi Edmund,
> 
> to me, this looks like a strong basis to start from, but obviously we're not a quorum.
> 
> I've taken your text and loaded it into the wiki [1] would very much appreciate others' reviews on this text, in particular
> 
> - any uncertainties in the language or logic
> - any gaps in the overall description
> - any use-cases we can think of that can't or won't fit into this scheme
> 
> br
> Paul
> 
> [1] https://gitlab.com/trustable/overview/wikis/hypothesis-for-software-to-be-trustable
> 
>> On 2017-01-31 10:34, trustable at panic.fluff.org wrote:
>> After some long discussions with Emmet Hikory
>> <emmet.hikory at codethink.co.uk> and Paul Sherwood
>> <paul.sherwood at codethink.co.uk> I'd like to offer the following as a
>> defintions for Software to be Trustable.
>> Nomenclature:
>>    A "change" is any change to standards, requirements, tests, code,
>> documentation, or other materials that affect the project, specifically
>> including the initial upload of any component of any materials.
>>    A "build" consists of any compilation, reformation, rearrangement,
>> or copying of any sources to generate any artefacts that may become
>> subject to test or deployment.
>> We know where it comes from:
>>    Any upload of any change must be certain to belong to some uploader.
>>        This implies an authentication mechanism in the patch tracker.
>>        This implies a mechanism to override SCM provenance information
>>            (Alice may assert Bob wrote a patch, but it was uploaded to
>>             the tracker by Alice, so the system must know this).
>>    Any upload of any change must have a facility for attestation of origin
>>        This implies metadata about changes beyond commit messages
>>    No import of foreign sources is without attestation of origin
>>    The SCM must have a gated branch with continuous history
>> We know how to build it:
>>    Any build must be performed by automation.
>>        This implies the build instructions must be machine readable
>>        This implies the build environment is produced by automation.
>>    We have a complete log, including environment details, of at least
>>      two apparently identical successful builds.
>> We can reproduce it:
>>    Any build performed twice must generate the same results.
>>        This implies the sources must allow reproducible build
>>        This implies the build environment must be isolated
>>    Any deployment performed must be performed by automation
>>        This implies the deployment instructions must be machine readable
>>        This implies that some trustable software does not have
>>            identical state after deployment.
>> It does what it is supposed to do:
>> It does not do what it is not supposed to do:
>>    Any requirement must be expressed in a manner that can be verified
>>        This implies the requirements are machine readable
>>        This implies tooling to generate tests based on the requirements
>>        The result of any test is machine readable
>>    Any software deployed to production has prior evidence of passing tests
>>        This implies pre-merge functionality in CI or similar
>>    Any change must be associated with a requirement
>>    There must exist information indicating the minimum tests required to gate
>>       These tests must encompass all requirements related to the subject
>>       of the change
>> We can update it and be confident it will not break or regress:
>>    Any update must undergo functional testing
>>        This implies pre-merge integration and testing.
>>        This implies stable build and deployment facilities
>> If all these statements are true then I would postulate that the
>> software could be regarded as Trustable..
>> I look forward to your opinions and views
>> Edmund
> 
> _______________________________________________
> trustable-software mailing list
> trustable-software at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20170203/c524d3dd/attachment.html>


More information about the trustable-software mailing list