Re: Processes HAVE been discussed to counter source-control archive attacks

[Werner Koch <wk () gnupg org>]

On Fri, 09 Jan 2004 11:42:24 -0500, David A Wheeler said:

> Good news: as a result of the break-in into Savannah, the
> Free Software Foundation (FSF) has offered funds to add to CVS
> a way to digitally sign all changes, and is discussing this with the

I don't think that this is sufficient for several reasons:

* The CVS server checking that a commit has been signed may already
  been compromised.  I am not sure how to implement such an
  enforcement on the client side because there is no guanateee that
  the developer has a sufficent new CVS software which ensures client
  side verification.

* The developers machines are notoriously insecure because they
  usually have to use all kinds of new software still being under
  development and who knows whether one piece has been trojaned.  Thus
  any code signing on the client side can be subverted.

* I doubt that all developers will take more care signing code than
  connecting through ssh to a CVS server.  For sure that signing will
  be scripted and no local review of the changes against the last
  signed version of a file will done.
 
I am now running an experiment: For Libgcrypt I started to sign the
code file by file and keep the signatures in a per-directory file
named Manifest.  As a simple counter measurement against malware on my
machine, I use a smartcard dedicatecd to code signing and only insert
the card when I am about to sign a file.  A simple script is then used
to verify the signatures and eventually this checking will be included
into "make dist".  The ultimate goal is to check the to be distributed
tarball and sign it on a machine not connected directly to the net.

For updating files, the signing tool should be able to retrieve an old
copy of the source with valid signatures and produce diffs to the
current file versions, so that the developer can decide whether to
sign it or not.

Yes, there are still lot of ways to compromise this scheme but it
raises the bar more than signed cvs commits.  At least the usual
toolchain (gcc, binutils, bash, autoconf, automake, libtool) should be
developed using a system like this.

The drawback is that it reduces the fun of hacking and ends up in
really hard and disciplined work.  Thus I don't believe that many
projects would care about it.

Thanks,

  Werner

-- 
Werner Koch                                      <[EMAIL PROTECTED]>
The GnuPG Experts                                http://g10code.com
Free Software Foundation Europe                  http://fsfeurope.org