On Aug 1, 2012, at 1:29 PM, Daniel Kahn Gillmor wrote:
> On 08/01/2012 01:12 PM, David Shaw wrote:
>> My point is that if you expect GPG to be able to fix a broken key, you need
>> to pass back all the data, or GPG has nothing to work from.
>
> well, you could expect the GPG of the original uplo
On 08/01/2012 01:12 PM, David Shaw wrote:
> My point is that if you expect GPG to be able to fix a broken key, you need
> to pass back all the data, or GPG has nothing to work from.
well, you could expect the GPG of the original uploader to fix the
broken key before uploading it. Then the keyser
On Aug 1, 2012, at 12:33 PM, Daniel Kahn Gillmor wrote:
> On 08/01/2012 12:44 AM, David Shaw wrote:
>> hiding the packets is potentially harmful. [...]
>> hiding the packets from GPG prevents this repair from happening.
>> After all, if GPG doesn't get the packets, it can't move them to the
> ri
On 08/01/2012 12:44 AM, David Shaw wrote:
> hiding the packets is potentially harmful. [...]
> hiding the packets from GPG prevents this repair from happening.
> After all, if GPG doesn't get the packets, it can't move them to the
right place. > This means the signatures are effectively lost,
f
On 2012-08-01 at 00:44 -0400, David Shaw wrote:
> Possibly a best of both worlds would be to have SKS do its cleaning, and then
> GPG, after it gained the ability to do a repair, would start requesting keys
> with "clean=off". This way, clients that could not repair would not get
> mangled keys
On Jul 31, 2012, at 6:04 PM, Kristian Fiskerstrand wrote:
> On 2012-07-31 23:29, David Shaw wrote:
>
>> What's happening here is that the key is mangled on SKS (whether SKS
>> mangled it or it was imported already mangled doesn't matter). GPG
>> fetches it, and there is some code to move misplac
On 2012-08-01 00:53, Daniel Kahn Gillmor wrote:
> On 07/31/2012 06:04 PM, Kristian Fiskerstrand wrote:
...
>
> If anything, the current sks implementation is violating RFC 4880, which
> clearly states that transferable public key certificates contain:
>
> - After each Subkey packet, one Si
On 07/31/2012 06:04 PM, Kristian Fiskerstrand wrote:
> Currently we have a patch[0] ready that allows for these signatures to
> be cleaned in the getting (and vindex) of the key,
A patch with the stated functionality would be a Good Thing.
> However, before creating a Pull Request into the SKS T
On 2012-07-31 23:29, David Shaw wrote:
> What's happening here is that the key is mangled on SKS (whether SKS
> mangled it or it was imported already mangled doesn't matter). GPG
> fetches it, and there is some code to move misplaced packets to the
> right place. Unfortunately, as you noticed, t
