[trustable-software] trustable-software Digest, Vol 10, Issue 4

Rupert D.E. Brown rupertb at cix.compulink.co.uk
Mon Apr 3 18:10:55 UTC 2017


There are no standards I am aware of - just the dreaded "best practise" - at UBS when we started the process the range of roles were very limited and mostly business facing. 
Might be worth a look at some US Govt standards that may be a bit more rigorous than general IT ones.
-R

-----Original Message-----
From: trustable-software [mailto:trustable-software-bounces at lists.trustable.io] On Behalf Of trustable-software-request at lists.trustable.io
Sent: 03 April 2017 17:11
To: trustable-software at lists.trustable.io
Subject: trustable-software Digest, Vol 10, Issue 4

Send trustable-software mailing list submissions to
	trustable-software at lists.trustable.io

To subscribe or unsubscribe via the World Wide Web, visit
	https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software

or, via email, send a message with subject or body 'help' to
	trustable-software-request at lists.trustable.io

You can reach the person managing the list at
	trustable-software-owner at lists.trustable.io

When replying, please edit your Subject line so it is more specific than "Re: Contents of trustable-software digest..."


Today's Topics:

   1. Re: Segregation of Duties (trustable at panic.fluff.org)
   2. Re: An experiment (Niall Dalton)
   3. Re: An experiment (Niall Dalton)
   4. Re: An experiment (Niall Dalton)


----------------------------------------------------------------------

Message: 1
Date: Mon, 3 Apr 2017 16:44:13 +0100 (BST)
From: trustable at panic.fluff.org
To: Trustable software engineering discussion
	<trustable-software at lists.trustable.io>
Subject: Re: [trustable-software] Segregation of Duties
Message-ID: <Pine.LNX.4.64.1704031641100.10136 at trinity.fluff.org>
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed


On Mon, 3 Apr 2017, Colin Robbins wrote:
> A.6.1.2 Segregation of duties Control. Conflicting duties and areas of 
> responsibility shall be segregated to reduce opportunities for 
> unauthorized or unintentional modification or misuse of the 
> organization's assets.
>
>

yes I've noted this in lots of standards, however it doesn't say what duties should be associated with which responsbilities..

For example, developers can only make changes in version control and in turn this gets deployed to test environments, However, only production administrated can log into production environments, not developers.

Another example, is those developers cannot review their own work.

These seem sensible but don't seem to be written down in any standards as requirements.

Edmund

--
========================================================================
Edmund J. Sutcliffe                     Thoughtful Solutions; Creatively
<edmunds at panic.fluff.org>               Implemented and Communicated
<http://panic.fluff.org>                +44 (0) 7976 938841




------------------------------

Message: 2
Date: Mon, 3 Apr 2017 08:51:44 -0700
From: Niall Dalton <niall.dalton at gmail.com>
To: Trustable software engineering discussion
	<trustable-software at lists.trustable.io>
Subject: Re: [trustable-software] An experiment
Message-ID:
	<CAE3J-bQLNP_w61kMGDinwvwnk5jRgJu+d45TchZde3J-30TeMw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Sun, Apr 2, 2017 at 7:01 PM, Don Brown <don.brown at codethink.com> wrote:

> Also, is Doorstop accessible online?
>
>
​I used this:​

https://github.com/jacebrowning/doorstop

​It creates a web of yml files; so at least the content can be rescued if
the system turns out to not be as useful as hoped.

​



>
>
> Thank you!
>
>
> --
> Don Brown
> Codethink, Ltd.
> Software Engineering Consultant
> Indianapolis, IN USA
> Email: don.brown at codethink.co.uk
> Mobile: +1 317-560-0513 <(317)%20560-0513>
>
>
>
> On 2017-03-31 06:59, Jim MacArthur wrote:
>
> A quick follow up: I'm working with Doorstop at the moment, and I'm
> looking for example requirements documents to codify. If you have
> requirements for Iota written in plain text/Word document etc, I'd be happy
> to help by trying to translate them into Doorstop. Maybe I'll find some
> missing features in Doorstop while I'm doing it :)
>
> Jim
>
> _______________________________________________
> trustable-software mailing list
> trustable-software at lists.trustable.io
> https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software
>
>
> _______________________________________________
> 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/20170403/68663fee/attachment-0001.html>

------------------------------

Message: 3
Date: Mon, 3 Apr 2017 09:00:10 -0700
From: Niall Dalton <niall.dalton at gmail.com>
To: Trustable software engineering discussion
	<trustable-software at lists.trustable.io>
Subject: Re: [trustable-software] An experiment
Message-ID:
	<CAE3J-bSAHbHs_Cyg-46_f6wRhjhXfQUYQA1MK5tJf48__v4qNw at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, Apr 3, 2017 at 2:30 AM, Jim MacArthur <jim.macarthur at codethink.co.uk
> wrote:
>
> That matches my understanding. That looks like a logical progression to
> me. Formal verification sounds like a long way off. At the moment, having
> looked around the FOSS world, I see a lack of published requirements
> documents in any form, so I'm wondering if we are jumping the gun a bit by
> recommending Doorstop and should encourage people to write and publish
> their requirements in any format first.
>



​Realistically, I'm going to write some plain text files first, so we can
have them in the repo. And then figure out if/how to encode in doorstop.​



Language choices are out of scope on this list since we are more interested
> in processes, and discussions on languages are rarely productive, but I
> think your approach is right. Thanks for reminding me that Oberon exists; I
> must research that again.
>


​Sure, language discussions are rarely productive. (Life might be easier if
we could agree they all suck, and move on ;-).​

​My point in bringing it up is that, by design, iota immediately has a
couple of problems. For one, it deliberately uses unsafe languages: there's
already assembly for 2 ISAs and some C.

I don't think there's a practical way to leverage Necula/Lee style
proof-carrying code (e.g. TalX86 for the the x86 assembly) so other than
the fact that I've tagged it and superficially tested it.. who knows if we
can trust it? Ditto on the C -- we're going to have to figure out how we
convince ourselves we're type and memory safe. E.g. I need to get the
sanitizer builds working so we can see that there are no wild pointers.

Re: oberon -- I'd personally make different design choices, but the
underlying philosophy of minimalism and simplicity is dramatically
underrated.

As the old (Hoare?) saying goes.. "There are two ways of constructing a
software design. One way is to make it so simple that there are obviously
no deficiencies. And the other way is to make it so complicated that there
are no obvious deficiencies.".

Of course, only the third way works.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20170403/cfeb5fd1/attachment-0001.html>

------------------------------

Message: 4
Date: Mon, 3 Apr 2017 09:11:14 -0700
From: Niall Dalton <niall.dalton at gmail.com>
To: Trustable software engineering discussion
	<trustable-software at lists.trustable.io>
Subject: Re: [trustable-software] An experiment
Message-ID:
	<CAE3J-bT42w9DhXXdAB-Ta4+Htk+nFX9V=JxWBpnhAfKnnhzF4g at mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

On Mon, Apr 3, 2017 at 6:43 AM, Paul Sherwood <paul.sherwood at codethink.co.uk
> wrote:

> I know who you are, Niall, and would take that into account when deciding
> about the trustability of any work that you show.
>
> Ideally you have a way to assert and demonstrate that the work you are
> showing really comes from you.
>


To show the work comes from me: I've tagged the initial files via a gpg
key​, and asserted my identity via keybase. I won't tag each commit, unless
readers would really like that, but periodically sign some part of the
chain of commits (given it's effectively a Merkle 'tree' we should be ok).
Sound good?

​To show the work is trustable: WIP -- we need to figure out more how to
check that.​



> 2) ​Follow some standard rules/recommendations. Mostly these seem to cover
>>> the relatively easy cases -- I've not seen anything that'll help me in more
>>> realistic street-fighting code.
>>>
>>
> Clearly we are still only collecting rules + recommendations, and I think
> we are at the tip of this iceberg so far.
>
> Ultimately no-one has time to check manually that you have actually
> applied rules + recommendations comprehensively, so I think we need to be
> aiming for software/tools in this area, including at a minimum
>
> - linting and code style checking
> - static analysis
> - dynamic analysis
> - test coverage
> - fuzzing
> - stress testing
>
> Am I missing some categories?
>


​Probably.. but that's already a bunch of stuff to automate (which I'll
take a look at -- pointers welcome).

Touching on the formal stuff you mention, it includes a lot of nice work on
formalizing memory models. I enjoy the work on the x86/arm/power memory
models, and the semantics of C and C++ models -- however I've yet to
connect that to day to day coding. Other than staring at lockfree code and
quibbling informally.

​I'll read further on REMS and DeepSpec.​


Particularly on FOSS projects, development has been 'middle out'
> - create some code to scratch an itch
> - in the process of testing/using/sharing, discover more itches
>
> I think we need to make it easy to describe each itch, and map the itches
> to tests, and give developers clear reasons to keep updating itches and
> tests as part of their core process.
>
> So I believe we need to be able to treat requirements (and official
> standards) in the same way (and as part of the same pipeline) as code.
>


​Yes!​

​I'm all for all the good things that comes from doing the design work,
peer review, etc. However, as you note, I also have to fight my 'code
first, that stuff later' tendencies. Letting me work with them as something
near to code would certainly help me live up to such expectations.
​
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20170403/8076fb87/attachment.html>

------------------------------

Subject: Digest Footer

_______________________________________________
trustable-software mailing list
trustable-software at lists.trustable.io
https://lists.trustable.io/cgi-bin/mailman/listinfo/trustable-software


------------------------------

End of trustable-software Digest, Vol 10, Issue 4
*************************************************




More information about the trustable-software mailing list