Why trust any software?

[kardan]

Hi,

I would like to widen the view of this thread as the question not only
apply to windows software in my eyes.

On Thu, 25 Jul 2013 21:17:43 +0000 atair <atair04 at googlemail.com> wrote:

> This basically means, that everyone(!) can access, modify and
> redistribute the source code of the program (see [2] if you're
> interested). There are lots of people (usually volunteers from all
> over the wold) who do peer reviews on the sources (and if you start
> with [2], _you_ can be another one). Therefore, changes that look like
> back doors are VERY unlikely to find their way in a release, because
> hundreds of people are looking how the software evolves and will
> reject such a patch.

This is heard very often. How can I check if this is true for a
particular piece of software? For the kernel reviews can be tracked via
LKML but not every code is so popular. How to see how many people really
read and approved a patch for example? Also the number may not be that
relevant than if experienced developers did.

On Fri, 26 Jul 2013 09:22:32 -0400
"Mark H. Wood" <mwood at IUPUI.Edu> wrote:

> But it takes only one person who can and does do this inspection, to
> reveal the evil deed.  And that person could be anywhere.  He very
> likely won't be identified until he announces his presence by
> announcing his discovery of the attack.

I would love this person even showing up to approve if there is no
attack - just for me feeling better.

On Fri, 26 Jul 2013 00:14:08 +0200
"Julian H. Stacey" <jhs at berklix.com> wrote:

> However you missed the point that many MS users are not programmers,
> & will not be compiling their own binaries, so any malign entity
> could regularly hack their nasty extras in, compile & issue binaries
> that dont match published source [...]

Also many linux users look strange at me if I say I do compile parts
of my debian system.

Fri, 26 Jul 2013 09:22:32 -0400
"Mark H. Wood" <mwood at IUPUI.Edu> wrote:

> Well, Windows users who aren't programmers, who switch to e.g. Linux,
> will then be Linux users who aren't programmers, so this alone changes
> little for the individual.  He is still dependent on others in the
> community.  That is quite alright -- an important part of PKC is for
> people to find out for themselves who is reliable and form open-eyed
> trust relationships.

Can you please explain what you mean by PKC in this context?

Do you know of signing mechanisms for developers to
 A have special keys for signing code changes
 B sign each others keys to approve they are knowledged enough to
 understand and check the code reliably.
 C sign a piece of software/patch/commit with it
? Also it is interesting to differ between source and binaries -
tracking source changes and builds separatedly or even confirm a
trust chain with a combination of both.

> One can't assume whoever offers a .exe has used a the same free GCC
> compiler for MS aka http://www.cygwin.org that we might by default
> reach for.
> 
> It would be hard Work, comparing & analysing different _binaries_
> not _sources_ to differentiate benign irrelevant differences from
> link order & tools used, & maybe date stamp & trace of compiler
> host & licence number, as opposed to possible differences from to
> malign source manipulation,
> 
> I wouldn't waste time working unpaid analysing MS binaries to protect
> clueless MS end users.  More fun to develop source code for projects.

There is a discussion going on [1] about this proposing deterministic
builds system like gitian [2]. What do you think of it and is this
applicable to gnupg as well?

kardan

[1] http://lists.debian.org/debian-security/2013/08/msg00003.html
[2] https://gitian.org/

-- 
Kardan <kardan at riseup.net>
Encrypt your email: http://gnupg.org/documentation
Public GPG key 9D6108AE58C06558 at hkp://pool.sks-keyservers.net
fpr: F72F C4D9 6A52 16A1 E7C9  AE94 9D61 08AE 58C0 6558
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: not available
URL: </pipermail/attachments/20130805/b776bf12/attachment.sig>