gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] (fairly minor) SECURITY ISSUE


From: Colin Walters
Subject: Re: [Gnu-arch-users] (fairly minor) SECURITY ISSUE
Date: Wed, 21 Jan 2004 03:28:54 -0500

On Tue, 2004-01-20 at 22:45, Tom Lord wrote:

> This is a fairly bogus idea, unfortunately.  Which of many signatures
> should arch use to check a file? 

The check script should use whichever it wants - some or all of them.

>  Which should it fetch from a server?

All of them.

> You go on to suggest that .check scripts should be pointed at a
> directory of all available signatures but that has two drawbacks:  1)
> it requires the creation of a temporary directory (the current
> interfact to .check scripts does not require tmp files at all) 

And that's a big deal why?

> and 2)
> it needlessly increases the number of (archive) filesystem
> transactions needed to examine a given revision.

In the typical case there'll just be one signature, so all we're adding
is one operation to read the directory.

> Anyway: What is the semantic significance of multiply signed revisions

That multiple people or groups confirm the revision is valid.

> and why doesn't that functionality belong elsewhere?  

Because in order to build this on top of tla, you'd basically have to
reimplement most of the signature/checksum work.

> The purpose of
> signatures in arch is to help to preserve archive integrity.  Period.

Well, what is "integrity"?  The answer to that depends on the threat
model.  If your threat model doesn't include hostile users or people
cracking your system, then cryptographic signatures are basically
noise.  

But in the real world those things happen, of course.  Multiple
signatures are a good thing here.  Suppose that in a project you have
several regular developers, plus a developer dedicated to security
audits.  The regular developers all commit to one archive, and revisions
will be signed by their individual keys.  The auditor's work will be to
verify the changesets, and once they pass review, he adds his own
signature to the revisions in the archive.

In this scenario, the compromise of an individual developer's account
and key doesn't mean all is lost - the auditor's signatures are still
there.  Likewise, given a compromise of the auditor, revisions can still
be verified against the developer keys.

How is this different from the auditor creating his own mirror of the
archive and signing the revisions himself?  Simple - it keeps all the
signatures in one place, which allows both signatures to be preserved
when the archive is mirrored.  Otherwise, you'd have to mirror *both*
the normal archive and the auditor's archive, which would basically be a
waste of space.

> Arch's syntax requirement on signing tools is pretty unobtrusive.  It
> requires that it be able to unambiguously find it's pretty
> conservative syntax for checksums amidst whatever noise is introduced
> by whatever signing process is used. 

Right, and we've already seen how that causes problems...

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]