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

[Tom Lord]

    > From: Robert Collins <address@hidden>

    > On Mon, 2003-12-08 at 06:13, Tom Lord wrote:

    > > 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=20
    > >    a passphrase and record it.

    > Are you [sure] about this? 

No.  But pretty sure.

    > GPG goes to some lengths to ensure
    > that in-memory passphrases aren't swapped out, so as to prevent
    > presence in cores etc.  There are passphrase daemons around that
    > can provide passphrases automatically (see q-agent).

Well, passphrase agents are certainly worth considering -- I don't
know anything about them yet.   I do think that they should be an
option rather than a requirement.

GPG goes to lengths, sure, but pretty much nothing else in the system
actually cooperates with that.   There they are in my xterm scrollback,
for example.


    > > 7) treat the passphrase "copy" specially.

    > This feels wrong.=20

    > I think a better way to indicate copying of signatures is via an
    > explicit parameter, not via a magic passphrase.

No particular objection to that.   I think it would be reasonable
enough to have a set of "pass-thru" parameters from commands that open
archives to the transport layer.

On the other hand, though, it isn't a priority.   What I suggested
works just fine and is simpler to implement.


    > There is another thing to note: you haven't provided anywhere to declare
    > which gpg uid / key to sign with. It's not uncommon for folk to have
    > more than one signing identity.

Sorry, I should have been explicit that the other reason to post to
the list about this is because my GPG and crypto experience is rather
limited.

Generally, though, I think my plan is a good starting point and that
adding additional parameters here and there is easy enough to do in
retrospect -- I don't see anything in what you've said so far that
undermines the basic plan I posted.


    > Now, in a multi user archive, there may be different folk committing
    > with their own keys. So, an archive-specific metadata to select the
    > committing key won't support multiple committers. Therefore we can
    > either have some local metadata associated with the location, or we can
    > use a parameter to commit (and/or a field in the user edited log file).

    > I suggest --gpg-key=3D<string> to commit, and have no field name to
    > suggest at this point.

Perhaps that can be the net effect but for fairly good reasons I want
to avoid introducing gpg stuff into the archive abstraction of
libarch/archive.h.

Signing the files is really a transport thing.   Hypothetically, in
the future, we could explore signing the file contents -- but that'd
be way too much work just to get this working in a useful way.

Why the distinction between signing files and signing file contents?
Because, for example, not all semantically equivalent tar.gz files are
byte-for-byte identical and a smart server might want to generate
tar-bundles on the fly rather than literally recording the one that
the client sent in the first place.

-t