[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