[trustable-software] An experiment
trustable at panic.fluff.org
trustable at panic.fluff.org
Mon Mar 27 23:06:12 UTC 2017
Niall,
>Should I...
> * specify some requirements in YAML for "iota" and track in git? are
there existing templates?
I certainly I would do this. My choice in this space is to make
use of DoorStop
https://doorstop.readthedocs.io/en/latest/
As for encoding the requirements I've found a couple of ways to
desribe them work very well.
* https://tools.ietf.org/html/rfc2223 RFC like material
* https://martinfowler.com/bliki/GivenWhenThen.html
> * specify my tests, expected tools, language standards etc. also in
> YAML in git? are there open tools I can use to check standards
> compliance mechanically beyond gcc flags?
If found particularly using RPSEC implementations.
If I'm doing this sort of thing I tend to use something which
works at the OS level. I'm particularly taken with
https://blog.liw.fi/posts/yarn/
* write my code + tests, assuming normal use of git is enough to track
provenance?
In terms of standards compliance generally the important things here
are the principles of many eyes, and the ability to have details
of who worked on requirements and that being reviewed and
implemnented and test by a group of people. Providing this
evidence is important and helps with compliance.
If you use pgp signing for the identities you improve this
on your pushes to central repos.
* how should we systematically link between code, requirements and
tests?
I'm not a fan of monorepo approaches to building things. There
needs to be to hold linkage information between the repositories
which contain the tests and the requirements and the
implementations in my view
You could do this with git-submodule, though I find this a
little clunky and unhelpful. I've currently making use of
http://gitman.readthedocs.io/en/latest/
to hold this linkage and relationship between
requirements in DoorStop (YAML in git),
tests in (YARN in YAML in git)
source code in (C in git)
* again, within git, link systematically between bugs and fixes?
I'd make an argument that bugs a typically because tests or
requirements aren't producting the behaviour required.
I would deal with these as just additions to the requirements
repository under DoorStop control. This would lead to merges
and reviews to that repository and the implementation of test to
confirm function (perhaps YARN in a git repository) and then fixes to
the code to ensure we have things in a good approach
* mechanically check that everything is tested, including no space leaks
etc beyond usual coverage?
So depending on the language, static code analysis and code coverage
tools will help with this and putting this into you Continuous
integration and test chain and putting these test results into
perhap annotations to the test data or in a seperate signed
repository would be a big help.
> What else would make iota more trustable than other code?
I'd take a look at some of the work being done on reproducible
builds. I've been following the development of BuildStream
which is trying to address this.
https://blogs.gnome.org/tvb/2017/02/06/introducing-buildstream-2/
The demos work, which is a good start but I've done no more
> What else would give us confidence we could put this on the internet
> for an open capture-the-flag competition to break it?
I would encourage a bug bounty, very much in the form that
Don Knuth did with TeX and MetaFont
https://en.wikipedia.org/wiki/Knuth_reward_check
Hope this gives you a start
Edmund
--
========================================================================
Edmund J. Sutcliffe Thoughtful Solutions; Creatively
<edmunds at panic.fluff.org> Implemented and Communicated
<http://panic.fluff.org> +44 (0) 7976 938841
More information about the trustable-software
mailing list