Re: security vs. configure

[Tom Holroyd]

On Mon, 23 Apr 2001, Michael Still wrote:

> Autoconf could run gnupg / pgp (if present) after generating the configure
> script and produce a checksum on the script. If this was a default action,
> then it would increase the chance of developers having at least some
> checksumming.
>
> It doesn't fix doubt over the intentions of the developer though.

The developer might have good intentions but a) evil mirrors, b) trojaned
build tools, c) compromised ftp servers, etc.  If a build environment is
already compromised, the situation is nearly hopeless.  The idea is to
prevent that from happening.

If you use automake, it is a good idea to have it output rules that make
signed tarballs (or at least sha1sum, md5sum, or sum style checksums if
signing software is unavailable).

(Note that you really want to sign the .tar file, not the .tar.gz file,
because some browsers automatically decompress .gz files, and re-gzipping
them won't produce the same checksums or signatures.)

What would be nice is if it were possible for configure to automatically
check the signature or checksum.  Since that's hard to do on an unpacked
archive, signed packages might go the "tarball inside a tarball" route,
where the configure script actually unpacks the real tarball after
checking the signature.

        $ tar -xzf file_you_just_downloaded.tgz
        $ cd project_dir_created_by_tar
        $ ls
        configure       project.tar     project.tar.asc

with maybe a few README, INSTALL, COPYRIGHT, and other (non-executable,
non-data) boilerplate files.  Then configure does all the integrity
checking.

Is it hard to have a default macro you can add to Makefile.in (even if you
don't use automake), like

@MAKE_MD5SUM_DIST@ $(DIST_FILES)
or
@MAKE_GPGSIGNED_DIST@ $(DIST_FILES)

that expands to the right lines to create tarballs as above?