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

[Robert Collins]

On Mon, 2003-12-08 at 07:17, Tom Lord wrote:
> 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.

Thats easy: just prompt each time you need a passphrase. An agent will
detect and supply, and if not using one, you just get good at typeing.

> 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.

They shouldn't be, as gpg hides the key input - unless you terminal
doesn't support that?

>     > 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.

Yup, basically sound.

>     > 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.

For auditing, a smart server will need to keep the gpg signed tarballs
and log files. So, while it may generate whatever it wants on the fly,
and sign it with a server key,  to show that address@hidden
commited patch-45, it will /need/ the original tarball, and the original
signature.

How do you suggest that key selection be implemented then?

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.

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