This key
http://zimmerman.mayfirst.org:11371/pks/lookup?op=getsearch=0xED34CEABE27BAABC
is buggy. It contains a generic certification packet on the first subkey
and a positive certification packet on the second subkey.
From a quick glance at the SKS source code, it looks as though the
Clint Adams just reported:
http://bugs.debian.org/683328
This key is buggy:
http://keys.mayfirst.org/pks/lookup?op=getsearch=0xED34CEABE27BAABC
Note the 0x10 and 0x13 signatures on the 4096-bit subkey; these
should not be there.
Please check the signature types and only
On 2012-07-31 00:32, Daniel Kahn Gillmor wrote:
I think his analysis is correct, although:
0) i don't have a patch to propose, and
1) i'm not sure how to deploy such a fix across the whole keyserver
network, since it looks to me like it would effectively appear as a
filter change.
On Tue, Jul 31, 2012 at 03:00:25AM +0200, Kristian Fiskerstrand wrote:
I'm testing out a patch[0] at [1] . Could you please confirm that this
is to your expectation?
Yes, that looks good!
Note that this is implemented in the cleaning layer for vindex and get,
and not on the data store, so
On Jul 30, 2012, at 3:20 PM, Clint Adams cl...@gnu.org wrote:
This key
http://zimmerman.mayfirst.org:11371/pks/lookup?op=getsearch=0xED34CEABE27BAABC
is buggy. It contains a generic certification packet on the first subkey
and a positive certification packet on the second subkey.
On Jul 30, 2012, at 11:01 PM, Clint Adams cl...@gnu.org wrote:
On Mon, Jul 30, 2012 at 10:10:10PM -0400, Jeffrey Johnson wrote:
0x10 - 0x13 on a subkey to my reading. Meanwhile, the
whole issue of what other signatures might be applied to
subkeys afaik: the usage of pubkey signatures (other
