[geekcrypt] Re: Back door competition
- From: Pid Zero <p1dz3r0@xxxxxxxxx>
- To: "geekcrypt@xxxxxxxxxxxxx" <geekcrypt@xxxxxxxxxxxxx>
- Date: Fri, 6 Jun 2014 08:39:38 +0100
By all means incentivise people to find bugs, that's one of the benefits of
FOSS. But I'll have no part in any project that actively attempts to embed
vulnerabilities into the code. It's going to do more harm to the trust
users have in the product (we already suspect NSA/GCHQ involvement without
the projects own devs subverting the code too), let alone the possibility
that if one of the devs is compromised it presents perfect cover for the
insertion of malicious code ("oh that backdoor is part of the game, I'll
remove it, honest" *wink wink*). It's a bad idea.
On Friday, June 6, 2014, Niklas Lemcke - 林樂寬 <compul@xxxxxxxxxxxxxx> wrote:
> Well, if you insert as part of the competition, hoping to "win" e.g.
> for it not to be discovered, and immediately write an encrypted
> message telling about the backdoor; and if the others are actively
> searching (which is supposed to be promoted through this) and want to
> see the decrypted message at the end of the two weeks, then I don't
> think we will 'forget' one.
>
> It would be easy to go through each 'encrypted message' and double
> check if all backdoors are gone before each release.
>
> Of course we need to be cautios. But I think it can help to promote
> awareness in the team.
>
>
> On Fri, 6 Jun 2014 07:46:03 +0100
> Pid Zero <p1dz3r0@xxxxxxxxx <javascript:;>> wrote:
>
> > I'm a little dubious about actively trying to weaken the code for fun.
> What
> > if we forget a backdoor? I'm just as concerned about initial TLA
> > involvement, but other than have every other dev check each other's work
> or
> > write the same code in parallel I can't see how you'd get around it.
> > Decentralising so that as few devs as possible have access to accept
> > commits and sign the binaries (I.e. Segregation of duties & least
> > privilege) are good practices to adopt to mitigate any mole impact.
> >
> > In either event rebuilding trust is going to be difficult within the
> > established community without the potential for the scandal that would
> > arise if one of us were found to have knowingly inserted a backdoor which
> > we forgot about and was later exploited by a TLA like the NSA!
> >
> > On Friday, June 6, 2014, Bill Cox <waywardgeek@xxxxxxxxx <javascript:;>>
> wrote:
> >
> > > On Fri, Jun 6, 2014 at 12:46 AM, Niklas Lemcke - 林樂寬 <
> > > compul@xxxxxxxxxxxxxx <javascript:;>
> > > <javascript:_e(%7B%7D,'cvml','compul@xxxxxxxxxxxxxx <javascript:;>');>>
> wrote:
> > >
> > >> I am completely in love with that "thought" of yours! It'll keep
> > >> everybody on the run, while also offering good learning opportunities
> > >> for the rookies / non-core developers.
> > >>
> > >> Let's do it. Maybe once every week would be a little short. Maybe
> every
> > >> two weeks?
> > >>
> > >> What do the others think?
> > >>
> > >> Niklas
> > >>
> > >
> > > Two weeks works for me. Also, it would be fun to track how many back
> > > doors we each find. We could begin to get a sense for who is good at
> > > creating back doors, and who is good at finding them. I'm guessing
> they
> > > will be different people :-) This might also provide a useful metric
> for
> > > developer performance. The #1 value a core developer brings to the
> team,
> > > IMO, is trust in the code, and this could help us understand who is
> most
> > > able to create that trust. That could help a lot when it's time to
> promote
> > > a developer to core-developer.
> > >
> > > Bill
> > >
>
>
>
> --
> Niklas Lemcke - 林樂寬
>
> At the time of writing, no warrants have ever been served to me, Niklas
> Lemcke, nor am I under any personal legal compulsion concerning the
> CipherShed project. I do not know of any searches or seizures of my
> assets.
>
Other related posts: