Phil Pennock:
Is it known that when you do sks dump N dir, you end up with up to
10 stack frames per N, plus the calls into the DB layer, etc?
[...]
I was suspecting db problems, and it's not. Looks as though something
was expecting tail recursion optimisation but not getting it. I really
I can now dump keys without segfaults (thanks, Kim). I have some
questions for people who generate dumps already.
I've been shutting down sks db recon while dumping; in practice, do
people find that sks dump is safe to run while the db is running?
If I want to switch sks to using one of my own
Each of the attached compiles, which means more than it does in some
other languages. I'm fairly confident I haven't messed up. But there's
two approaches.
Previously, membership was only automatically reloaded in the db server,
not the recon server.
Patch sks-mshp-timed.patch makes membership
Phil Pennock:
Previously, membership was only automatically reloaded in the db server,
not the recon server.
Why do you say this? Reading Membership.get and Membership.test, the
file is reloaded whenever it is modified. thus this patch seems wrong.
Kim Minh.
On 2009-03-22 at 12:47 +, Kim Minh Kaplan wrote:
Phil Pennock:
Previously, membership was only automatically reloaded in the db server,
not the recon server.
Why do you say this? Reading Membership.get and Membership.test, the
file is reloaded whenever it is modified. thus this
Phil Pennock:
8 cut here 8--
=item -membership_reload_interval
Maximum interval (in hours) at which membership file is reloaded.
8 cut here 8--
There are supposed to be *two*
I was seeing this in recon.log:
2009-03-22 08:34:10 Error getting missing keys: Out of memory
This is because the server makes use of the response even though the
request failed. It then proceed onto erronously alloc huge amount of
memory (which sometimes fail). On most systems this is not
On 03/22/2009 09:02 AM, Kim Minh Kaplan wrote:
Daniel Kahn Gillmor:
gpg generates an HTTP request like this:
http://$foo:11371/pks/lookup?op=indexoptions=mrsearch=0xD21739E9exact=on
[...]
What is the right way to handle this?
The simplest solution would be to remove the exact=on
On Mar 22, 2009, at 11:08 AM, Daniel Kahn Gillmor wrote:
This makes me think that what we're seeing is a bug in older
versions of
SKS that could cause serious incompatibilities. The reason i found it
was a report from a user who was having difficulty searching for keys
from the keyservers by
On 03/22/2009 06:41 PM, David Shaw wrote:
The 'exact=on' problem is specific to 1.0.10. It worked properly in 1.0.9.
See: http://www.mail-archive.com/sks-devel@nongnu.org/msg00287.html
Ah, thanks for the pointer, David.
Given that this causes problems for users of gnupg, has any thought
I'm really confused. People have piped in in both directions on this one,
so does someone have the definitive story? Is 1.0.10 the one that behaves
correctly, or 1.0.9?
And yes, we should get a 1.0.11 release out soon. I was waiting for the
IPv6 patch to settle down and for everyone to agree
2009/3/22 Phil Pennock sks-devel-p...@spodhuis.org
The gotcha here is async DNS support in O'Caml.
I'm sure I'm missing something here, but why is asynchronous DNS a
requirement? Why not do the DNS queries using threads?
y
___
Sks-devel mailing
On 03/22/2009 10:29 PM, Yaron Minsky wrote:
I'm really confused. People have piped in in both directions on this one,
so does someone have the definitive story? Is 1.0.10 the one that behaves
correctly, or 1.0.9?
So far i haven't heard anyone claim that 1.0.10 works correctly. 1.1.0
works
On 2009-03-22 at 22:40 -0400, Yaron Minsky wrote:
2009/3/22 Phil Pennock sks-devel-p...@spodhuis.org
The gotcha here is async DNS support in O'Caml.
I'm sure I'm missing something here, but why is asynchronous DNS a
requirement? Why not do the DNS queries using threads?
You're not missing
14 matches
Mail list logo
