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

[Tom Lord]

    > From: Thomas Zander <address@hidden>

    > On Monday 08 December 2003 16:59, Tom Lord wrote:
    > >     > From: Thomas Zander <address@hidden>

    >>> The external file-signing method that you proposed is only used
    >>> for whole files. With that I mean the compressed versions.  Its
    >>> not really good to sign the content of the tar with a file that
    >>> is not _inside_ the tar itself since that means gpg --verify
    >>> x.will not work.

    >> Is there something wrong with `--verify SIGFILE FILES'?
    >> Standard Savannah/GNU practice for signing FTP sites is to use
    >> detached signatures.

    > Your previous messages led me to believe you did not want to
    > sign the tar file itself, since that can be unzipped/rebzipped
    > or something. But the uncompressed stream (without tar headers).

    > If that indeed is the case; then your `--verify SIGFILE FILES'
    > is indeed wrong; since you need to uncompress that tar/gz before
    > being able to do that.

    > Well; its not _wrong_ per see, but there is a better solution
    > since the external signing is meant to be used for a file that
    > is present in the same dir as the signature file.

There are two separate questions:

  1) Can signing be made an essential property of all (present and
     future) arch archives, including "smart server" archives and
     the like?

  2) Can signing be made an implicit property, essentially hidden 
     from the bulk of the code in arch, of all existing "dumb-fs"
     arch archive implementations?

When I say "I don't want arch signing the tar bundles because they
might be reconstructed later" -- I'm talking about question (1).

To satisfy the immediate needs of Savannah, the FSF, and really the
free software community generally, I'm looking for an answer to
question (2).  For question (2), signing the actual tar bundles seems
like a pragmatic choice.  The trick is to do (2) without hosing the
architecture of arch (by leaking knowledge of signing into too much
of the internal interfaces of libarch).


-t