gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] (volunteers?) crypto signatures for arch
Date: Sun, 7 Dec 2003 12:49:53 -0800 (PST)


    > From: Robert Collins <address@hidden>

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

For push-mirror (the expected common case), the number of such prompts
is unbounded.  Even for `tag' it'll take 3 runs of GPG.  I'd like to
avoid requiring the user to install an agent just to use this
feature.  I'm skeptical that such a requirement would actually
strengthen security in any meaningful way.


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

Sorry -- xterm core image, then.


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

That's not true.  It can verify the incoming data, protect it, and
discard the original tar-ball and signature.

    > How do you suggest that key selection be implemented then?

So far, pass-thrus from command-line to transport seem the best option
to me.   Alternatively, we could have some persistent data (some
.arch-params thing) that only the transport layer looks at.


-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]