[Top][All Lists]

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

Re: [task #4633] GPG-Signed Commits

From: Derek Price
Subject: Re: [task #4633] GPG-Signed Commits
Date: Sat, 24 Sep 2005 12:08:52 -0400
User-agent: Mozilla Thunderbird 1.0.6 (Windows/20050716)

Jim Hyslop wrote:

> Derek Price wrote:
>> Mark D. Baushke wrote:
>>>> Example:
>>>> CVSROOT=:local;sign-id=jhyslop@dreampossible.ca:/cvs
>>> Good point. For commits to the savannah.nongnu.org
>>> repositories, I might want to use a PGP keyid of 0xFCE72F65
>>> where another repository might use a PGP keyid of 0x161913F8.
>> I'd rather keep this more general, like sign-template="/usr/bin/gpg
>> --detach-sign --output - -u 0x161913F8".  The spaces might need to be
>> escaped to get them in a CVSROOT, but maybe not.
> Just so I'm clear what you're proposing, what I've called "sign-id"
> you'd rather have as "sign-template" with the args as specified,
> right? If that's the case, then that sounds reasonable (if maybe a
> little more effort to type in initially ;-)

Yes, but it should only need to be typed once, or maybe once per fresh

> Getting back to the -g option mentioned earlier in this thread, would
> the same syntax be used there as well? For example, if I wanted to
> override the template for a specific command, could I specify:
> cvs -g"/usr/bin/gpg --detach-sign --output - -u 0x12345678" ci

Well, no.  -g would enable CVS's default template, equivalent to a
CVSROOT like :ext;sign:....  --sign-template=whatever would set the
template on the command line.

> Also, it would be nice if we could provide separate means for
> specifying the basic signature commands ("/usr/bin/gpg --detach-sign
> --output -") and the user ID ("-u 0x..."). Since the majority of the
> command will remain the same regardless of the GPG ID used to sign the
> key, it would simplify dealing with multiple servers.

Yes, it would be nice, but it complicates other code.  To implement
this, two templates are necessary for each sign command, since gpg, at
least, will assume a default key-id when none is supplied on the command
line and we can't rely on every signing program to accept `-u KEYID' to
set a key to use for signing.  So, CVS would need to run "/usr/bin/gpg
--detach-sign --output - %f" when the user didn't supply a -u KEYID
argument to CVS and "/usr/bin/gpg --detach-sign -output - -u %k %f" when
the user does supply a keyid to CVS. 

I can see the argument that KEYID would be a common user request, but it
complicates the code.  I suppose maybe an argument could be made that
our default template would handle gpg, and that's what most of our users
would be using anyhow...

Hrm...  how about this for more generic:  --sign-template, as above,
except it defaults to "/usr/bin/gpg --detach-sign --output - %A %f", and
%A is substituted with any arguments passed to --sign-arg (or a sign-arg
method option).  So, assuming the default template, a CVSROOT like the
following could set a key id:


> If you mean processing recursively, then CVS doesn't currently support
> that anyway, does it?

Yes, I do mean that, and yes, CVS does support it.  See the "multiroot"
tests in sanity.sh.



Derek R. Price
CVS Solutions Architect
Ximbiot <http://ximbiot.com>
v: +1 717.579.6168
f: +1 717.234.3125

reply via email to

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