[Gnu-arch-users] (volunteers?) crypto signatures for arch

[Tom Lord]

There have been several (including some very recent) irc chats about
adding cryptographic signatures to arch.  My understanding is that
there might be some people interested in implementing this.  I can do
this myself but I thought I'd post a plan for it here in case somebody
wants to jump on it have some fun with it.

The FSF has recently requested this feature:

    > From: Richard Stallman <address@hidden>

    > Here's a description of a feature we're planning to put into CVS,
    > and we'd like to have it in Arch as well.  Can you work on this?

    >      The key item we learned from the gnuftp crack was that with
    >      GPG-signatures on all source code data, it is a mostly
    >      trivial task to vet the source code for tampering after a
    >      break-in.  Our biggest worry isn't that the server is
    >      "owned" by an interloper -- it's that the interloper may
    >      have used her access to directly trojan the source we host.

[Of course, we recently saw an example of exactly such an attempt 
in the CVS mirror that BitMover hosts. -t]

    >      With the FTP system, GPG signing is a simple process; we
    >      needed only require software maintainers follow some rules
    >      and we implemented a few upload procedure methods that help
    >      them follow the rules.

    >      Savannah is a different story -- it hosts the source in a
    >      revision control system that keeps many versions of the
    >      historical development.  Since a crack can occur at any
    >      time, we must have a way to authenticate every version of
    >      every file on the system in an simple, automated way.  That
    >      way, after any future crack, it will be trivial to verify
    >      the integrity of every savannah source trees.

    >      Across savannah, developers make hundreds of new versions
    >      of files per day, so the process of signing each version
    >      must be extremely convenient from the developers' point of
    >      view.  This means that changes must be made to the revision
    >      control system to allow signatures to be easily submitted,
    >      stored, and verified.


Here is a plan for how to implement a first-cut at this feature:


1) Replace libarch/archive-fs.c with libarch/pfs-fs.c

   Currently, WebDAV, vanilla HTTP, FTP, and SFTP access all
   go through an abstraction defined in libarch/pfs.[ch]
   but, for historic reasons, local file system archives 
   are treated differently.

   It should be a fairly simple exercise to write libarch/pfs-fs.c,
   a module allowing local file system archives to also go through
   the pfs abstraction.

   The advantage of doing this as the first step is that it won't
   be necessary to implement signature support twice (once for 
   local file system archives, again for everything else).

   Writing a new pfs "subclass" is pretty easy.  Mostly it involves
   implementing functions to perform the operations:

        file_exists
        is_dir
        file_contents
        get_file
        directory_files
        put_file
        mkdir
        rename
        rmdir
        rm


2) Add a "signed-archive" property to archives

   Have a look at libarch/archive.c(arch_make_archive) and 
   arch_pfs_make_archive.   Note how the parameter dot_listing_lossage 
   is used.

   Add a similar parameter signed_archive, so that if you create
   an archive with --signed, =meta-info the in the archive will
   contain a file "signed-archive" containing the string "system
   cracking is lame".


3) Modify arch_pfs_connect to collect a passphrase

   It's a bit icky to keep the passphrase in tla's memory but I think
   it's more reasonable in this case than the alternatives.

   In libarch/pfs.c(arch_pfs_connect), after connecting, look for
   the "signed-archive" file.   If present, prompt the user for 
   a passphrase and record it.


4) Modify arch_pfs_put_file to optionally sign files

   If arch_pfs_put_file is asked to store a file in an archive 
   with "signed-archive" set, it should work by storing the file
   locally (in a tmp dir), invoking gpg --detatch-sign to sign
   the file (using --passphrase-fd to pass the passphrase) and then
   store both files.


5) Write a shell script to check the signatures in an archive.



That part of the plan takes care of a lot but it still has a 
limitation:  it will interact with push-mirror poorly.

If I push-mirror from any archive to a signed mirror, it will prompt
me for a passphrase to use to sign the revisions in the mirror (rather
than copying the signatures from the mirrored archive).

Prompting like that is reasonable (usually) if I'm pushing from an
unsigned archive to a signed mirror -- but not if I'm pushing from a
signed archive to a signed mirror.

Therefore: 


6) add a new field to `struct arch_archive' and param to
   `archive_connect'

  Add a parameter to archive_connect called `mirroring_from'.
  That parameter should be a `struct arch_archive *' and should
  be stored in the `struct arch_archive' being created by 
  connect.

  In other words, when connecting to an archive, you can declare:
  "I'm connecting to X in order to mirror from Y".


7) treat the passphrase "copy" specially.

   The string "copy" is a horrible passphrase -- so we'll take it 
   over:

   If the passphrase supplied by a user is "copy" and the archive 
   being opened has a non-0 `mirroring_from' field, then instead of
   using GPG to create .sig files,  grab the .sig files from the
   archive being mirrored.

   libarch/cmd-archive-mirror.c will be the one place where a non-0
   value is passed for `mirroring_from'.


The upshot of all of this is that, with the exception of the
`mirroring_from' parameter, the protocol for manipulating archives
is unchanged.   All of the signature magic is "hidden" in the
transport layer and verified by an external shell script.

-t