[trustable-software] Segregation of Duties

[Niall Dalton]

On Tue, Apr 4, 2017 at 1:35 AM, Paul Sherwood <paul.sherwood at codethink.co.uk
> wrote:
>
> 2) Practicalities
> - What happens when reviewer changes role to developer or vice versa?
> - And how do we spot/eliminate collusion between notionally segregated
> actors?
> - Assuming (proof of) segregation is required, how would we ever adopt
> existing software, where presumably we can't establish what
> identities/roles were applied?
>


​I'm a fan of cross-checking code; whether that means core review or tests​
developed by someone that did not write the code under test. Having been in
environments where that's strictly applied, and seen the stuff that
accidentally gets through.. it seems easy to imagine someone maliciously
getting a dodgy bit of code into the system.

To elaborate on the collusion problem, and the existing software -- that's
going to get really tricky if you depend on tools or libraries that my
collaborators have touched. E.g. don't let ken touch the compiler, or the
exploit won't even be explicitly in the code I submit, it'll be inserted by
the toolchain when it spots my trigger code. More straightforwardly, it's
not that hard to slip a slightly more complicated state machine by someone
-- esp. with distributed systems code -- that I later depend on to cause
something dodgy.

(Or the old-fashioned, buy the reviewer a beer and gently get them to do
you a favor of clicking yes on the code so that you can get it in by end of
day).

I don't mean to be discouraging, and like I say, I'm a fan of
cross-checking. But if there's a big incentive to get a malicious change
into the system, it doesn't seem likely to stop it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.trustable.io/pipermail/trustable-software/attachments/20170404/e06ad37c/attachment.html>