Re: security vs. configure

[Eric Siegerman]

On Mon, Apr 23, 2001 at 10:14:16PM +1000, Michael Still wrote:
> How many people use make dist though? My thinking was based on the fact
> that the configure script is the bit that people seem to be concerned
> about the most, because it is the first instance of some code being
> blindly run.

Just because it's the first instance doesn't make it the only
instance.  People who sweat more about configure viruses than
about hacked package source are ... confused.  The two are
instances of the same problem, and thus equally dangerous.  (One
could argue that the package source is usually bigger and
therefore harder to audit ... but then, it's usually more
readable than a configure script :-)

> Also, I imagine that people only regenerate the configure script when they
> have to. I might modify my code, but unless I am a new requirement I can
> check for with autoconf, why would I rerun autoconf?

Because "make" does it for me without asking.  Eg. if I check the
package out of CVS and configure.in gets a later timestamp than
configure by virtue of sorting after it alphabetically.

I'd have thought this was irrelevant, though.  I only need to
validate a package when I first receive it, ie. before I've made
any local changes.

> I think a checksum is enough. I don't know the developers of most packages
> from a bar of soap. At least with a checksum I know the file hasn't been
> changed from it's original.
> 
> Then again, they can always update the checksum when they modify
> configure.

Just so.  Of course, the problem with checking signatures is that
too often, the only source for the signer's key is the same web
site you got the package from.  Security provided by that
signature:  zero.

In theory, PGP's "web of trust" should give me a trusted path to
the key in question; in practice, I've yet to see that happen.
(I'm not at all well-connected PGP-wise ... which makes me pretty
typical, I think.  In other words, depending on the web of trust
is unrealistic, IMO.)

> I don't like the tarball inside a tarball approach... This adds another
> level of complexity and inconvenience for users, and I would think would
> concern most developers as well.

Neither do I.  If configure is expecting to untar the
sub-tarball, then every time you change configure.in, you have to
do a full "make dist"/untar cycle to test it.

> Perhaps we're looking at this wrong -- at some point people need to say
> that the user is responsible for their own security.

Ultimately true, of course.

> If a simple system
> can't be implemented to assist them, then perhaps they should be left on
> their own.

But this is most unhelpful.  It's the stance that gave the world
ActiveX.

--

|  | /\
|-_|/  >   Eric Siegerman, Toronto, Ont.        address@hidden
|  |  /
With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea.
        - RFC 1925 (quoting an unnamed source)