Your message dated Wed, 2 Jan 2008 07:30:18 -0500
with message-id <[EMAIL PROTECTED]>
and subject line Bug#458595: signing-party: caff doesn't offer control over
cert-level
has caused the attached Bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I am
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Debian bug tracking system administrator
(administrator, Debian Bugs database)
--- Begin Message ---
Package: signing-party
Version: 0.4.9-1
Severity: normal
Tags: patch
The caff binary signs keys at the default cert-level. Since the program
is primarily targeted towards meetings where keys are verified with a
higher trust level, it probably makes sense to allow users to configure
the level at which they are signing the key.
I've created a patch to add a config option, default-cert-level, which
is used if it exists, and if it does not, the --ask-cert-level option is
passe to gpg instead, meaning that the signer is asked what level to
sign the key at.
-- System Information:
Debian Release: 4.0
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.18-4-k7
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Versions of packages signing-party depends on:
ii gnupg 1.4.6-2 GNU privacy guard - a free PGP rep
ii libgnupg-interfa 0.33-6 Perl interface to GnuPG
ii libmailtools-per 1.74-1 Manipulate email in perl programs
ii libmime-perl 5.420-0.1 Perl5 modules for MIME-compliant m
ii libtext-template 1.44-1.1 Text::Template perl module
ii mailx 1:8.1.2-0.20050715cvs-1 A simple mail user agent
Versions of packages signing-party recommends:
ii libintl-perl 1.16-1 Uniforum message translations syst
pn libpaper-utils <none> (no description available)
ii libtext-iconv-perl 1.4-3 converts between character sets in
ii postfix [mail-transport-agent 2.3.8-2+b1 A high-performance mail transport
ii recode 3.6-12 Character set conversion utility
ii whiptail 0.52.2-10 Displays user-friendly dialog boxe
-- no debconf information
Index: caff/caff
===================================================================
--- caff/caff (revision 360)
+++ caff/caff (working copy)
@@ -1094,6 +1094,11 @@
foreach my $local_user (@local_user) {
my @command;
push @command, $CONFIG{'gpg-sign'};
+ if (not defined $CONFIG{'default-cert-level'}) {
+ push @command, "--ask-cert-level";
+ } else {
+ push @command, "--default-cert-level",
$CONFIG{'default-cert-level'};
+ }
push @command, '--local-user', $local_user if (defined
$local_user);
push @command, "--homedir=$GNUPGHOME";
push @command, '--secret-keyring',
$CONFIG{'secret-keyring'};
Index: caff/caffrc.sample
===================================================================
--- caff/caffrc.sample (revision 360)
+++ caff/caffrc.sample (working copy)
@@ -14,6 +14,10 @@
$CONFIG{'also-encrypt-to'} = [ qw{DE7AAF6E94C09C7F} ];
$CONFIG{'caffhome'} = $ENV{'HOME'}.'/.caff';
+# If you wish to set a default keysigning cert level, uncomment this option.
+# Otherwise, you will be asked what level to sign at for each key.
+# $CONFIG{'default-cert-level'} = 3;
+
# The options below need not be changed for normal operation.
# Paths to GnuPG binaries:
--- End Message ---
--- Begin Message ---
On Wed, Jan 02, 2008 at 09:31:23AM +0100, Thijs Kinkhorst wrote:
> On Wednesday 2 January 2008 00:41, Christopher Schmidt wrote:
> > I've created a patch to add a config option, default-cert-level, which
> > is used if it exists, and if it does not, the --ask-cert-level option is
> > passe to gpg instead, meaning that the signer is asked what level to
> > sign the key at.
>
> Thanks for your patch, but I'm not so sure how useful this is - cert-level is
> not used in trust path calculations so what do you gain by specifying it?
I guess I'm not understanding something then. If this is the case, then
you're right that the patch doesn't make sense. I'm going based on:
http://www.desktoplinux.com/articles/AT7966076367.html
I read this:
"The first condition specifies that either the key has been signed with
another key on your keyring that has been granted full owner trust, or
the key has been signed by at least three other keys on your keyring
that have been granted marginal trust."
And I thought that the 'cert level' was equivilant to the 'owner trust'
or 'marginal trust'.
If this is *not* the case, and I'm not understanding something, then
this option really shouldn't be used, and I see now that the article
also says:
"The second condition requires that the path of signed keys leading back
to your own key (and inclusive of) include no more than six keys, or
five 'hops'."
So it sounds like you're right, and this certification level has no
meaning for web-of-trust calculations which is all I care about.
I apologize for the noise: I'm Very New to this key signing thing, and
to be honest, that sentence in the article is the first time I'd seen
that said. Googling, I can see now that there are many articles on the
web that say exactly that.
So, you're right. This bug was base on my misunderstanding of the way
that trust is calculated based on the web, and although I still
(apparetly) have no idea what the certification level does, I'm willing
to admit that it doesn't do what I thought it did, and given that, this
bug should be closed.
signature.asc
Description: Digital signature
--- End Message ---
