[Gnu-arch-users] one more feature needed for signing

[Tom Lord]

[Rob: hold on before moving your changes down to pfs.c level -- 
 it may be better to keep them in archive-pfs.c:]

    > From: Andrew Suffield <address@hidden>

    > On Sat, Dec 13, 2003 at 08:33:41AM -0800, Tom Lord wrote:

    >> All files in the archive should be signed including =meta-info files,
    >> CONTINUATION files,
    >> .listing files,

    > No point signing those. They have only one correct value and are
    > trivial to verify directly; furthermore, they're acutely vulnerable to
    > replay attacks, so signing it accomplishes nothing.

That's true but:

a) there's no good reason to _not_ sign them _if_ they are generated
   client-side _and_ the signing mechanism is low enough in pfs that
   it isn't distinguishing .listing from any other kind of file.

   However:

b) we've actually missed something:

   I was going to leave it up to users to write their own scripts to
   crawl over an archive and validate signatures.  Actually -- that
   script needs a little bit more help from arch and the signing
   mechanism needs just a bit more to it.

   As proposed and built so far (modulo the need to sign a few files 
   that aren't being signed yet) we can:

        1) detect un- or improperly-signed files in the archive
        2) detect changes to or removals of previously checked parts
           of the archive 

   what we can't do is:

        3) detect illegitimate new adds of revisions or archive-cached
           revisions constructed by copying files from legitimate 
           revisions

   For example, here's an exploit:

        a) project commits patch-X which, due to a bug, creates a 
           security risk in the project.

        b) project commits patch-Y which reverts patch-X

        c) attacker creates patch-Z which is a copy of patch-X

   it's easy to detect that patch-Z is bogus -- but not by looking
   at the existing .sig files alone.

   A simple fix is:

        i) when creating a revision directory, create and store
           an additional file containing the lines:

                <fully-qualified revision name>
                <hash of CONTINUATION, if present>
                <hash of changeset, if present>
                <hash of full-text, if present>
                <hash of log>

           and sign that.

        ii) when creating an archive-cached revision, create
            and store an additional file containing the lines:

                <fully-qualified revision name>
                <hash of archive-cached tar bundle>

            and sign that.

        iii) supplement the signature checker with a tool that
             verifies the contents of those files:  both that
             the hashes are correct and that the fully-qualified
             revision name is the right one.

-t