Hello,
following a fire that destroyed my server, keyserver.kim-minh.com is
down. It had already long been kicked out of the pool because it did not
meet all the criterias. I will not be bringing it back.
Thank you to all the SKS network.
Kim Minh.
Daniel Roesler:
>Great! Will email you separately.
Please, keep the list copied. This will be interesting to many of us.
Kim Minh.
>On Sat, Jun 29, 2019 at 7:40 PM Yaron Minsky wrote:
>>
>> I don't have a lot of time to contribute, and I haven't really
>thought about the implementation or
Sascha Rommelfangen:
> Hi all,
>
> Is nobody else affected by this issue?
> Nobody able to reproduce it?
>
> Cheers,
> Sascha
Yes, searches for the words jr, cix and ie yield 16 keys that have
serverly been abused.
$ du -hc /tmp/key-*.pgp
29M
Jason Harris writes:
>
>> Kim Minh Kaplan wrote:
>>
>> Jason Harris writes:
>>
>>> Cool! What tool/code did you use?
>>
>> Homegrown tools. I use a simple C program to read KDB/keys and create
>a
>> single PGP file for each key.
Jason John Schwarz wrote:
> I pushed my command_timeout up to 180 seconds per Kim's recommendation, but
> that seems to cause the web interface to be very sluggish
> during the period of key loads. I assume that is because the single thread
> is busy. Any thoughts the trade off of the web
Martin Dobrev writes:
> 2019-01-29 14:20:05 1 hashes recovered from
> 2019-01-29 14:20:05 7594FE72B3E93A0350D9950B926F81A7
> 2019-01-29 14:20:11 1 keys found
> 2019-01-29 14:20:16 Requesting 1 missing keys from [188.138.x.x]:23371>, starting with 7594FE72B3E93A0350D9950B926F81A7
>
PM brent s. wrote:
> well, that's the issue - hkp won't pull it, gpg won't pull it either.
>
> anyone know of a way to dump/extract a specific key from the SKS DB?
> i'd imagine there'd be a bdb way to do it but i'm not that old.
I've just wrote a short snippet to pull out data directly from
Verioweb SKS writes:
> Hi all together,
>
> due to the GDPR discussion and the devs not moving from their point of
> view or at least trying to "hear" the users supporting the network I
> have decided to shut my services down. I will observe further
> development and support the network again
Kiss Gabor (Bitman) wrote:
> I can see such error messages in db.log:
>
> 2018-06-26 21:56:18 Del'ng hash EF2602E9CC075BFEE833DFB9004582F3
> 2018-06-26 21:56:18 Del'ng hash F25AE814C4A6B721013179B9F4D36D87
> 2018-06-26 21:58:41 add_keys_merge failed: Eventloop.SigAlarm
> 2018-06-26 21:58:52 Key
Hendrik Visage wrote:
> ==> recon.log <==
> 2018-01-29 18:05:16 error in callback.:
> Sys_error("Connection reset by peer")
>
> I’m seeing these type of error messages, which is great to know that it
> happened, but it begs the question: Who/what was the peer that reset the
> connection?
>
Phil Pennock wrote:
> Fixes under keyserver operator control:
> * add a cron-job to signal SKS to regenerate stats
This could be changed into fixe for SKS keyserver:
* Continuously maintain up to date stats.
--
Kim Minh.
___
Sks-devel mailing list
hn Gillmor wrote:
> On Tue 2016-12-20 12:24:56 -0500, Kim Minh Kaplan wrote:
>> - to do this keyservers will have to actually do cryptography
>
> I think i disagree here. The keyservers currently don't validate
> anything, and i don't see how this proposal would change things.
>
>
Daniel Kahn Gillmor wrote:
> i've been trying to make it possible for key to state that
> it should be excluded from some keyservers, but those attempts to fix
> things have failed thus far due to filter synchronization issues:
>
>
>
Danny Horne wrote:
> On 18/11/2016 8:29 am, Kristian Fiskerstrand wrote:
>> http://dnsviz.net/d/pgp.key-server.io/dnssec/
>>
>> "key-server.io zone: The server(s) were not responsive to queries over
>> TCP. (66.33.206.206)"
>>
>
> https://intodns.com/key-server.io
>
> 'OK. Seems all your DNS
Brian Minton wrote:
> Kristian, is there a good way to easily check, e.g. with curl, the POST
> capabilities of a reverse proxy in front of SKS?
Not that easy. But you can try something like this:
printf '\000\000\000\000\r\n' >/tmp/data.$$
curl -so /tmp/hashquery.$$ --data-binary @/tmp/data.$$
Pascal Levasseur wrote:
>
> Please feel free to find the weaknesses in this suggestion !!!
You have no knowledgeable people to implement it.
--
Kim Minh.
___
Sks-devel mailing list
Sks-devel@nongnu.org
Jeremy T. Bouse wrote:
> The issue is the systems have 20GB drives and the sks database
> is 13GB. This presents the problem of I can't download a keydump, import
> it and delete it.
[…]
> So my question is does anyone have any thoughts on how best to
> handle?
Without modifying sks you could
Please keep the mailing list tuned in.
ma...@wk3.org ma...@wk3.org wrote:
Kim Minh Kaplan wrote:
I can see some functions that are not tail recursive¹ and could cause
some out of memory condition when “-n” is too big. We should probably
fix this. In the mean time check that your stack
ma...@wk3.org wrote:
I tweaked it with -n 64 (the machine got 32 GB of RAM). Sorry for not
paying due diligence when reporting, but that should still not crash the
process, or should it?
It crashes after the output of Loading keys...done with values -n 18 and
up.
I can see some
Brian Minton wrote:
I wonder if you could use haproxy as a non-http proxy for the recon
traffic.
I do not think it will work with stock SKS recon : the recon process
authorizes peers based on their IP address. I believe HAProxy masks
the original peer address.
--
Kim Minh.
Kiss Gabor (Bitman) wrote:
I can see recon as client error in callback.: Out of memory
messages and a certain amount of Reconciliation attempt from xxx
while gossip disabled. Ignoring.
I don't know if the later may cause the memory consumption.
Now I disable them at IP level.
Then let's
Gabor Kiss:
http://bakacsin.ki.iif.hu/~kissg/tmp/memory-day.png
May be hunt for misbehaving peers.
Flow analysis shows almost no traffic on port 11370
yesterday between 21:20 and 22:20 CET when memory consumption increased.
(937 bytes in 14 packets.)
So it is due other than excessive
Gabor Kiss writes:
Any idea?
May be hunt for misbehaving peers.
--
Kim Minh
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
Brian Minton :
And, related question: Will sks be okay if the dump files are modified
by an external process? I have a cron job set up to fetch the latest
dump files via rsync.
As you built your database using sks build then you are safe. Those
who use sks fastbuild MUST NOT modify the dump
Brian Minton writes:
When I first started my keyserver, I imported the dump without the fast
option. However, when running, the server process still has all the
dump files open (as shown by lsof.
On startup, SKS will open and keep them open all the files that are in
the dump directory. Even
Pete Stephenson wrote:
I was perusing my recon.log and db.log files today and noticed odd gaps
in gossip activity that last for an hour and result in error messages.
Logs for the last few days indicate this happens 10-15 times per day.
Maybe this is one of your peers misbehaving. You should
David Benfell wrote:
On Thu, Sep 04, 2014 at 02:31:38PM +0200, Arnold wrote:
On 04-09-14 08:16, Christoph Egger wrote:
Seems uploading my gpg key (d49ae731) to pool.sks-keyservers.net fails
for several of the hosts in rotation:
The question is: is the key too large, or should we accept
David Benfell wrote:
I'm noticing that sks dumps are taking a *very* long time, much longer than
when I first started doing them.
The one this morning took about 2.5 hours. At first, they were taking more
like a half hour.
I'm guessing that the database has not grown by five times in the
Phil Pennock:
2. bind a socket per address family, ensure the address families remain
distinct, let people run with defaults, of 0.0.0.0 and ::.
[...]
IMO, SKS should either set v6only on the accepting sockets explicitly
I have just submitted a pull request for this. Please have a look at
Daniel Kahn Gillmor writes:
But it seems like there are two approaches that could
be taken to fix it, and only one of them ought to rely on IPV6_V6ONLY:
a) sks could set IPV6_V6ONLY on all listening sockets, and require the
administrators to explicitly list IPv4 addresses differently from
John Clizbe :
I'm perfectly fine with bumping
the minimums to Ocaml 3.12.1
Reading http://caml.inria.fr/distrib/ocaml-3.11/notes/Changes apparently
IPV6_ONLY is available since Objective Caml 3.11.0.
--
Kim Minh
___
Sks-devel mailing list
Daniel Kahn Gillmor :
2013-11-27 12:37:17 Reconciliation attempt from unauthorized host ADDR_INET
[:::94.142.241.93]:54518. Ignoring
What does your sksconf file look like? It should explicitly list all the
IP address you want to serve.
--
Kim Minh
Thomas Spycher wrote:
i’m trying to generate some statistics out of my running sks keyserver. For
this i’m accessing the berkeley Database directly.
I was a bit surprised, that i can’t use the received public key in my python
script directly as binary based key.
[...]
It is not a error in
Stephan Seitz writes:
I'm more concerned about the following entries:
Reconciliation attempt from ADDR_INET [REDACTED]:55073 while gossip
disabled. Ignoring.
These attempts are done by about 20 different IPs. I compared a few of
the PTR records against the servers in the membership file
Phil Pennock wrote:
What do folks think of the idea of having sks dump also create a file
called [prefix]keycount.txt ?
[...]
Does this seem reasonable and worth coding?
This sounds interesting, but I would go a step further. There are
numerous information about a key dump that could be of
Stephan Beyer:
please touch your membership files to note SKS about changes;
sks.pkqs.net IP changed from 88.198.41.86 to 213.133.103.71.
The recon.log tells me that it is already syncing with some servers.
Is touching not required any longer in recent SKS versions?
SKS will pick DNS
Phil Pennock :
I'd tried to make sksclient be read-only in BDB access, but failed to
find a way to do so because a directory-based BDB *always* seems to use
log files. So I'd given up and gone with the flow.
Apparently the locking is not what it could be, as I ended up with a DB
that
Jeffrey Johnson :
On a somewhat related note (before I dig into OCAML), can anyone
state the retry loop algorithm that is currently implemented for
non-responding peers?
It's a long time since I worked on this but if I remember correctly, the
current algorithm is to continuously repeat:
-
John Clizbe writes:
Oddly, I was looking at a different problem last night and noticed this
snippet appearing twice in wserver.ml:
188-189
let rec parse_headers map cin =
let line = input_line cin in (* DOS attack: input_line is unsafe on
sockets *)
201-202
let parse_request cin =
This is just a short notice that keyserver.kim-minh.com has new IP
address:
94.23.239.69
2001:41d0:2:7245::5e17:ef45
If you find any problem with the new setting do not hesitate to tell me.
--
Kim Minh
___
Sks-devel mailing list
Jeffrey Johnson wrote:
the Ptree access pattern should be looked at carefully. I've
seen a number of failures attempting to tune with minimal locks
usually when accessing (or initially loading) the PTree store.
The access pattern on the PTree store is more complex than the raw KDB
store.
I
John Clizbe wrote:
Are we using the most efficient schema for the database? Page sizes and other
default DB creation settings and tunables?
I have started running some benchmarks. First results are available at
https://www.kim-minh.com/pub/sks/sks-database-tuning. The short
answer is that we
David Benfell :
Phil's post reminds me that we're solving the wrong problem here.
The truth is we don't care what country any particular server is in.
We care what server is closest in terms of routing across the
Internet.
The Right Thing would probably be anycast but I doubt any of us is
Ryan writes:
The GeoIP country database should be plenty accurate for this
Plenty enough for a pet project, sure. But my guess would be that
keyserver.fr is in France, not in Russia. This is in no way intended as
a critic of your project but only as a reminder that geolocation by IP
Commits d79d269c37e6 and 454a88931caf are not right. Althought the
wording may be awkward what the doc said was right. Here is my
understanding after reading fastbuild.ml. It reads a batch of keys
from the dump file then prepare commits it into Berkeley DB. The
number of keys in each batch is
Samir Nassar wrote:
I tried passing options=mr to op=get on several servers
http://sks.spodhuis.org:11371/pks/lookup?op=getoptions=mrsearch=0x983DF2C1CEF3F3DD
I only seem to get back HTML output. Is this as designed?
For op=get, options=mr does not change anything: the output is both
HTML
Samir Nassar wrote:
On 08/30/2011 18:09 , Kim Minh Kaplan wrote:
You do not have to change SKS to do what you want. You should not
use SKS HTML output but use it as a webservice : do a HTTP request
asking for machine readable output, parse and display that as it
suits you.
Does SKS
Samir Nassar wrote:
options=mr only seems to work for op=vindex and op=index and not for op=get
It works fine for op=get too: SKS outputs a RFC 2440 OpenPGP ASCII
armored key. And many tools actually use op=get to retrieve keys. SKS
being a notable exception :-)
--
Kim Minh.
Samir Nassar wrote:
Also, how HTML
is built up in SKS is problematic for people who want to integrate SKS
into their websites without sticking out like a sore thumb.
These things are fixable without changing the codebase too much.
You do not have to change SKS to do what you want. You should
Sebastian Urbach :
Please be advised that key-server.de is changing his tld to
key-server.org. Please change the tld accordingly in your config files.
IP and all other stuff stays the same.
The .de tld has quite a bit registered time left but wont be extended
anymore.
Note that the IPv6
Andrey Korobkov:
I can't understand, what's with my server:
It's iowait is so high, that it responds so slow, that keyserver pool treats
it as unresponding.
Why does it requesting many hundreds and thousands of keys, and what does it
really doing with them?
2011-04-11 23:54:32
http://code.google.com/p/sks-keyserver/updates/list shows 12 new
revisions (one merge) in the repository this week.
--
Kim Minh
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
John Clizb writes:
Kim Minh Kaplan wrote:
http://code.google.com/p/sks-keyserver/updates/list shows 12 new
revisions (one merge) in the repository this week.
No idea what happened to mine. Yaron said he'd look at them but never heard
back.
Look better: 10 of those revisions are yours
Kiss Gabor (Bitman) writes:
2011-04-04 14:32:57 Reconciliation attempt from unauthorized host ADDR_INET
[:::144.206.177.99]:22154. Ignoring
As far as I can see the problems started 3 days ago when I reconfigured
sks to accept connection on IPv6 too:
-
# Set hkp
Андрей Коробков writes:
The only problem is to have such a huge key database being built from dump
on my memory-limited 32-bit home server. When I tried to do the thing on my
64-bit desktop
and then copy the DB files to server, SKS didn't want to start because of
something like
__db.003
Patrick R McDonald writes:
I am looking to move liberty.antagonism.org to different hardware to
provide better service. It will also allow me to offer the server as a
hidden service. I search the web for a backup and restore instruction
for SKS, but was unable to find anything useful.
Андрей Коробков writes:
On Tue, 05 Apr 2011 08:23:59 +
Seems that db is totally broken:
On my desktop:
# db4.6_verify ptree
OK
On server:
[...]
# db4.6_verify ptree
db4.6_verify: __db.001: unable to find environment
# db4.6_recover -ve
Apparently while the DB itself is
Phil Pennock:
http://www.mit.edu/afs/net.mit.edu/project/pks/thesis/paper/thesis.html
Another resource you might find useful is the expired draft: The OpenPGP
HTTP Keyserver Protocol (HKP)
https://datatracker.ietf.org/doc/draft-shaw-openpgp-hkp/
--
Kim Minh
Andy Ruddock writes:
I planned to run another keyserver solely on my local network, in
order to be able to take the backup machine offline to create keydumps
from, without the need to take the main keyserver down.
Note that Jason Harris seems to have a much more interesting technique
for
As a quick and *dirty* implementation of key deletion I see two possibilities:
1. One way would be to add a blacklist file of keyids that the server
will refuse to add to its own database. This would probably have to
be complemented with a blacklist of fingerprints dynamically
maintained by the
Matt Kraai:
I haven't been able to figure out
how to make sks listen on both IPv4 and IPv6.
You need SKS 1.1.1 for IPv6 support.
--
Kim Minh
___
Sks-devel mailing list
Sks-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/sks-devel
Jeff Johnson writes:
1) no means to filter pubkeys. Some pubkeys are getting quite
large, approaching 100's of Kb.
Last year I did some investigations on keys size in the SKS network and
was surprised to find some multimegabytes keys. I only looked at the
largest and it was because of a huge
Hello,
since Berkeley DB 4.8 XA resource manager support has been dropped. SKS
never used this feature but as it is referenced in the driver SKS can not
be built against newest Berkeley DB releases. Yaron, can you put patch
7d8bb8cf29 from
Fabio M. Di Nitto writes:
I have decided to stop running the service.
Whoever can modify http://code.google.com/p/sks-keyserver/ should remove
http://keyserver.fabbionne.net from the page.
--
Kim Minh
___
Sks-devel mailing list
Sks-devel@nongnu.org
Javier Henderson writes:
I run two keyservers, one has just two peers, the other has about a dozen.
The one with a dozen peers sees periodic corruption, necessitating a rebuild.
From what I've seen after asking the great google mind, this seems to happen
periodically, and there was even a
Andy Ruddock writes:
Hi,
I'm currently rebuilding the database for keyserver.rainydayz.org.
I'm using the normalbuild rather than the fastbuild.
I'm presuming that the process displays the time taken after it's
processed each file, which means that the rebuild is going to take about
three
Jeff Johnson writes:
I am talking about catastophic recovery, particularly
in the sense of hardening, as in not having to reload
an entire database, for certain types of failures.
The procedure for catastrophic is described in depth in the Berkeley DB
manual. In particular if you want to be
Jeff Johnson writes:
On Feb 24, 2010, at 6:01 PM, Kim Minh Kaplan wrote:
Jeff Johnson:
The PTree deadlock is easily reproduced, and (with db_stat) a
detailed deadlock diagnosis could be attempted.
How would that be?
Deadlock diagnosis is described in chapter 11 here
Jeff Johnson:
BTW, can someone describe -- even superficially -- what is
being attempted with the PTree store? Any details are welcomed,
I'm not yet able to read OCAML code well enough to recognize
what type of store is being attempted.
The use of the prefix tree is described in the two
Sebastian Wiesinger wrote:
2010-02-01 07:17:31 Requesting 100 missing keys from ADDR_INET
[79.18.143.39]:11371, starting with 0058751DD7011D0C0A2FB5CB04F462C1
2010-02-01 07:18:33 Error getting missing keys: End_of_file
This is probably the source of your problem.
--
Kim Minh.
Ryan :
I am introducing a new hostname for this SKS Server, pgp.webtru.st. The
original hostname of keys.nayr.net will remain, and all the http ports will
redirect you to the new hostname.
Please update the host as soon as convenient.. or not, within the next year I
will be deploying
MailFighter.net Admin writes:
What I still need is to configure my mailsync file, and test incoming pks over
email.
Do you know people using PKS? The subject comes up here regularly
regarding how SKS should behave with regard to PKS. Their input would
be precious.
The only errors so
Phil Pennock:
I just wrote this:
http://code.google.com/p/sks-keyserver/wiki/Peering
Nice work. Here are some hopefully constructive comments.
You are assumed to have installed SKS
You could explicit that you mean something like make make install
or aptitude install sks as peering
Phil Pennock writes:
It's running 1.1.0;
That's the reason I could not reproduce: this has changed in 1.1.1 where
only the host and port are reported on the stats page.
Kim Minh.
___
Sks-devel mailing list
Sks-devel@nongnu.org
John Marshall writes:
On Sun, 30 Aug 2009, 23:02 +, Kim Minh Kaplan wrote:
may be the
documentation change I did is not right and should read Can be a list
of whitespace separated IP addresses or domain names.
Yes, changing the documentation patch as
you suggest above would be good
Minh.
# HG changeset patch
# User Kim Minh Kaplan kaplan+...@kim-minh.com
# Date 1251646824 -7200
# Node ID c77aab222f08dc7469d43eb1b5cc171ca1e997f4
# Parent d351d05877dca577dce3463675dc9e4e44f973ea
Call Unix.getaddrinfo on both hkp_address and recon_address.
diff -r d351d05877dc -r c77aab222f08
John Marshall writes:
check whether the
*_address lists are IP addresses or domain names and handle
configuration accordingly.
If my understanding of getaddrinfo(3) is correct this is exactly what
the patch I sent should do. It does not work for you? Or may be the
documentation change I
Yaron Minsky writes:
Sounds like another good patch!
On Fri, Aug 14, 2009 at 2:45 PM, Kim Minh Kaplan kaplan+...@kim-minh.com
wrote:
Note that one reason of the excessive slowness
of build is because of a strange tuning of database, namely pagesize.
By default it is set
Yaron Minsky writes:
Neither of those revisions appear to be in the hg repo you mentioned:
[ymin...@minskyprimus sks]$ hg log http://www.kim-minh.com/hg/sks/ -r
977e38781686
abort: unknown revision '977e38781686'!
[ymin...@minskyprimus sks]$ hg log http://www.kim-minh.com/hg/sks/ -r
Sebastian Wiesinger:
I tried to specify both an IPv4 and IPv6 recon address like this:
recon_address: 88.198.253.20
recon_address: 2001:7b8:38e::abcd
That didn't work. How can I specify both addresses for outgoing recon
connects?
Put them on the same line, separated by spaces:
Jason Harris writes:
Without the selective pull(s), you still arrive at version c67b2f226c24,
but also copy/preserve all of K-M's intermediate work, get the multiple
heads problem, and clutter the commit log with entries you don't care
about (unless you use hg log -f).
The selection part is
Sebastian Wiesinger:
Put them on the same line, separated by spaces:
recon_address: 88.198.253.20 2001:7b8:38e::abcd
and do the same for hkp_address.
That doesn't work for me:
$ /usr/sbin/sks -debug recon
Fatal error: exception Failure(inet_addr_of_string)
You need version 1.1.1.
Dinko Korunic writes:
I reckon this is because of initial import duration (build vs pbuild)
only. Personally, I am against using pbuild exactly for reasons you said.
Are you talking of build vs fastbuild? You can not do without pbuild
for the recon process. Note that one reason of the
Jason Harris:
I would suggest the output go to its own logfile, like update_subkeys:
update_subkeys.ml:121: set_logfile update_subkeys;
and be verbose by default (assuming I got my extra output because I set
debuglevel: 5 in sksconf):
This fixup script does not really deserve to be
Phil Pennock writes:
Kim Minh Kaplan wrote:
Is a command for manually (automatically?)
reindexing the database without rebuilding necessary?
Necessary, no. Nice to have, yes. But I'll just shut down, take a
copy, start back up, run dump/init on the new system and then switch
over later
This should correct the word index.
$ ./fix_word_index
2009-08-08 13:35:41 Fixing word index
2009-08-08 13:38:04 Fixed 17247 words
I even believe you can run it without stopping the SKS db server but I
am not certain, feedback on this part would be very appreciated as I am
still
Phil Pennock writes:
Hi Kim,
It's been a while since I looked at the code-base; does this require a
dump and reindex or will the index changes be picked up anyway?
Thanks,
-Phil
Ah yes I forgot to mention that you need to rebuild the keys and ptree
databases from scratch. Is a command
Jonathon Weiss:
Hi All,
It was pointed out to me that searching for the full name associated
with key 0xF5832DD7C85CC5AD did not find the key, though searching for
just the first name did. Actually searching for just the last name
seems to fail too. The random 2 other SKS servers I
Dinko Korunic writes:
On Fri, Jul 03, 2009 at 06:07:19PM +, Kim Minh Kaplan wrote:
Now that my patches have been included in his repository,
the only reason I publicize mine is so that people who do not want to
bother with Mercurial can download an archived (tar.gz) version easily.
Last
Leonhard Kugler:
compiling the sks-1.0.10 by hand.
Better get a newer version from http://minskyprimus.net/sks/releases/
(see this thread
http://lists.gnu.org/archive/html/sks-devel/2009-03/msg00087.html)
Kim Minh.
___
Sks-devel mailing list
Phil Pennock writes:
On 2009-03-29 at 07:55 +, Kim Minh Kaplan wrote:
Regarding recon_address some additional care is needed because other
SKS peers use the IP address for authentication purposes. As current
SKS code does *not* support IPv4 mapped address you should *not* use
Hello Phil,
sorry for the late reply, I was working on the patches for the release.
By now most of your remarks have been answered one way or another :-)
Phil Pennock writes:
For the new config rules of yours, sks.pod should probably show how to
enable IPv6 cleanly with:
hkp_address:
Fix DNS staleness.
Resolve partner's addresses every time it is choosen for recon.
Kim Minh.
diff -r 4458db9d61bf membership.ml
--- a/membership.ml Sat Mar 28 10:49:51 2009 +
+++ b/membership.ml Sat Mar 28 11:10:32 2009 +
@@ -42,16 +42,12 @@
let local_recon_addr = Utils.unit_memoize
Servers can listen on multiple addresses simultaneously.
The settings -recon_address and -hkp_address are extended to accept
multiple IP addresses separated by spaces.
Kim Minh.
diff -r 0b3ca8c14f6f -r b1c6270313e0 common.ml
--- a/common.ml Wed Mar 25 13:37:28 2009 +
+++ b/common.ml Wed Mar
Fix non tail recursion in sksdump.
http://lists.gnu.org/archive/html/sks-devel/2009-03/msg00090.html
Kim Minh.
diff -r e30dc5376cbb -r b49747d1b1d0 sksdump.ml
--- a/sksdump.ml Fri May 23 21:16:40 2008 -0400
+++ b/sksdump.ml Wed Mar 25 12:08:39 2009 +
@@ -46,19 +46,22 @@
match
Recon server check that the HTTP request succeeded before using the response.
Kim Minh.
diff -r b49747d1b1d0 -r 38b920ada3e2 reconComm.ml
--- a/reconComm.ml Wed Mar 25 12:08:39 2009 +
+++ b/reconComm.ml Wed Mar 25 12:14:08 2009 +
@@ -65,6 +65,8 @@
with
Not_found - false
+let
Servers can listen on multiple addresses simultaneously.
The settings -recon_address and -hkp_address are extended to accept
multiple IP addresses separated by spaces.
Kim Minh.
diff -r 0b3ca8c14f6f -r b1c6270313e0 common.ml
--- a/common.ml Wed Mar 25 13:37:28 2009 +
+++ b/common.ml Wed Mar
This second patch on SKS 1.1.0 prevents a unknown client from keeping
partners out when one of the partners has a broken DNS server.
Kim Minh.
diff -ru sks-1.1.0.orig/membership.ml sks-1.1.0-dnsfix-2/membership.ml
--- sks-1.1.0.orig/membership.ml 2008-05-08 01:05:54.0 +
+++
Phil Pennock writes:
So, the IP addresses will be held internally after all?
Yes. In fact they are already.
How long for? When do they expire?
Until the next time sks recon process tries to connect to a partner, at
which point a knew DNS lookup is done for *this* particular partner and
it
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
1 - 100 of 110 matches
Mail list logo
