On May 31, 2012, at 1:58 AM, John Clizbe wrote:
>>
>> Why is crypto needed? It's a set of RFC 2440/4880 expired packets that
>> match a pubkey fingerprint that need to be dropped when retrieved: parsing
>> is needed but not crypto afaik.
>
> Look at clean again, and by extension minimal. First
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA256
Kiss Gabor (Bitman) wrote:
>> The easiest solution would be to auto-expire keys after a fixed time
>> (a good strategy anyway from a security perspective).
>
> What about deleting expired signatures from keys?
&option=clean in my earlier email
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA256
Jeffrey Johnson wrote:
>
> On May 30, 2012, at 10:58 PM, John Clizbe wrote:
>
>> Jeffrey Johnson wrote:
>>>
>>> Its the expired robo-signatures on existing pubkeys, not
>>> the pubkeys, that need filtering. There is also a need to
>>> delete
> > If I was related to certain Asian governments I'd set up a fake key
> > server that is the only reachable from the country then I'd
> > serve manipulated keys to certain clients.
>
> How do you propose to manipulate those keys? Do you have some way of
> breaking RSA that we don't know about?
On 05/31/2012 12:57 AM, Gabor Kiss wrote:
> There is no guarantee that one can trust all of current key servers.
This is why users are encouraged to use a keyserver they *do* trust.
This is why keyserver operators are encouraged *not* to peer with others
they don't trust. Some operators on this
> I'm with Rob. The keyservers should always host full certificates. Once we
> start expiring keys or modifying them by removing bits, we become the
> Untrusted Keyserver Cabal. Many would abandon us, probably forking to create a
There is no guarantee that one can trust all of current key servers.
> The easiest solution would be to auto-expire keys after a fixed time
> (a good strategy anyway from a security perspective).
What about deleting expired signatures from keys?
Gabor
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.
On May 30, 2012, at 10:58 PM, John Clizbe wrote:
> Jeffrey Johnson wrote:
>>
>> Its the expired robo-signatures on existing pubkeys, not
>> the pubkeys, that need filtering. There is also a need to
>> delete pubkeys
>>
>> Is there a solution that can filter out specific expired
>> signatures o
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1,SHA256
Yaron Minsky wrote:
> John? Seems like you're the main person who I haven't heard a response
> from. How do you feel about switching to bitbucket?
>
Sorry for the late reply, Long weekend at BF's place. And a slew of catch up
once I got home.
Jeffrey Johnson wrote:
>
> Its the expired robo-signatures on existing pubkeys, not
> the pubkeys, that need filtering. There is also a need to
> delete pubkeys
>
> Is there a solution that can filter out specific expired
> signatures on pub keys that can be gossip'd efficiently?
>
> AFAIK addit
On May 30, 2012, at 9:22 PM, Ari Trachtenberg wrote:
> The problem with the second plan is that the potential number of differences
> between hosts could grow quite large, degrading performance.
>
> The easiest solution would be to auto-expire keys after a fixed time
> (a good strategy anyway f
The problem with the second plan is that the potential number of differences
between hosts could grow quite large, degrading performance.
The easiest solution would be to auto-expire keys after a fixed time
(a good strategy anyway from a security perspective).
Best,
-Ari
On May 30, 2012,
Thanks for creating a clearly separated fork. I look forward to seeing the
source!
Cheers,
y
On Fri, May 25, 2012 at 2:05 PM, Sebastian Urbach wrote:
> Hi,
>
> Sorry, the usual friday dump is a bit late today but it's available
> right now:
>
> http://key-server.org/dump/
> ftp://key-server.org
I see reconciliation errors caused by mismatched filters. I suspect
that this is simple version skew.
Now that we have both SKS and GnuKS, *before* people start adding new
filters, should we add the current filters to the status page, early
enough to try to get both variants to include the featur
Here's my quick sense of what the reasonable solutions are:
- Add a key-deletion authority, as Gabor suggested. These deletion
certificates would be gossiped around, and would lead to deletion of keys.
The deletion certificates would stick around for a long time, but they'd
be small,
John? Seems like you're the main person who I haven't heard a response
from. How do you feel about switching to bitbucket?
y
On Wed, May 30, 2012 at 7:45 PM, Yaron Minsky wrote:
> My mistake. It is now public, and allows forks and all. Tell me if you
> have any further issues.
>
>
> On Sun,
My mistake. It is now public, and allows forks and all. Tell me if you
have any further issues.
On Sun, May 27, 2012 at 4:50 AM, Kristian Fiskerstrand <
k...@sumptuouscapital.com> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> On 2012-05-26 18:49, Yaron Minsky wrote:
> >
> > Mig
On Sat, May 26, 2012 at 8:35 PM, David Benfell wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 05/26/2012 05:12 PM, Matthew Palmer wrote:
> >
> > Given that (I believe) the source code to sks is already stored in
> > a mercurial repository, it would make sense to use a mercurial
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2012-05-30 06:11, Phil Pennock wrote:
> I do not run with SKS in a VM and have never experienced the clock
> problem, so can't test if the attached patch resolves any problems.
> I can confirm that I can receive a key from a peer with this code
>
19 matches
Mail list logo
