I have rejected reconciliation connections from the host
reg.goeswhere.com; checking stats, I see that they have 27 configured
peers, but only 7 of those are mutual.
20 outbound configured peers where the peer does not have you configured
as a peer seems to suggest that someone has just added a
On 2013-08-14 at 15:16 -0400, Phil Pennock wrote:
On 2013-08-14 at 20:55 +0200, Christoph Anton Mitterer wrote:
On Wed, 2013-08-14 at 04:08 -0400, Phil Pennock wrote:
* stinkfoot.org
I'm one of it's two peers...
Not sure why reco doesn't work here... the server still uses my old DNS
recommended
reverse-proxy setup for SKS.
The SKS versions section of the Peering wiki page has more details.
Please add me as follows:
sks-peer.spodhuis.org 11370 # Phil Pennock keyser...@spodhuis.org 0x3903637F
Thanks,
-Phil
pgpvF74r9icsl.pgp
Description: PGP signature
Kristian and I have been talking about identifying those SKS servers
which have limited connectivity. He's going to follow up tomorrow with
more details from the canonical pool definitions. In the meantime, for
your horror and entertainment, how I generated a graph and a link to the
graph.
It
:
keyserver.skoopsmedia.net 11370 # Adam Lewicki 0xF3E88A9F
Done, but with a...@lewicki.at added in as a contact email address.
Please add:
sks-peer.spodhuis.org 11370 # Phil Pennock keyser...@spodhuis.org 0x3903637F
Thanks,
- -Phil
-BEGIN PGP SIGNATURE-
iEYEAREDAAYFAlIBd6IACgkQQDBDFTkDY3
On 2013-07-31 at 15:48 +0200, Christoph Anton Mitterer wrote:
2013-07-31 05:16:15 Raising Sys.Break -- PTree may be corrupted:
Failure(add_to_node: attempt to reinsert element into prefix tree)
2013-07-31 05:16:15 DB closed
I looked around in the archive and past reports mentioned problems on
On 2013-07-09 at 17:07 +0200, Stephan Seitz wrote:
We've noticed that the redirection of http://pool.sks-keyservers.net/ at
different pool-members could be a big show-stopper for the average user.
I know, that doesn't matter for most of us, but it's obviously not a big
deal to setup a unique
On 2013-06-28 at 17:59 -0400, Phil Pennock wrote:
One of them has a simple document describing the commands available:
http://pgp.mit.edu/emailhelp.html
Oh, that doesn't describe how to upload; sorry.
This one does:
http://www.pgp.net/pgpnet/email-help-en.html
If you're modifying code
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2013-06-26 at 22:50 +0200, Kristian Fiskerstrand wrote:
On 06/26/2013 10:48 PM, Phil Pennock wrote:
I'm not remembering anything in the spec about a primary UID;
last I recall, all UIDs are equal sub-packets, right? Or is it
time
If you have an install of GnuPG 2 which is built using curl-shim, not a
real libcurl, then please read on.
You can tell the build by running:
/usr/local/libexec/gpg2keys_hkp --version
(or whatever the path is to the assistant). If it says:
Uses: libcurl/7.24.0 OpenSSL/0.9.8x zlib/1.2.7
then
On 2013-03-06 at 18:51 -0500, Eric Benoit wrote:
Lighttpd has rather limited header manipulation facilities, at least
in 1.4.x. I was just about ready to add this feature when I came
across a not very well documented option:
server.reject-expect-100-with-417 = disable
Which when added to
Off-topic but I think of interest:
http://www.xkcd.com/1181/
Title: PGP
-Phil
pgpF5MdJCVAit.pgp
Description: PGP signature
___
Sks-devel mailing list
Sks-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/sks-devel
On 2013-03-02 at 13:38 -0600, John Clizbe wrote:
Does not appear to be failing. I have not added the RequestHeader unset
Expect early directive you suggest. Perhaps this is sensitive to particular
releases of Apache?
That's what I was afraid of.
It's failing against keys.wuschelpuschel.org
On 2013-03-02 at 20:39 -0500, Phil Pennock wrote:
On 2013-03-02 at 13:38 -0600, John Clizbe wrote:
Does not appear to be failing. I have not added the RequestHeader unset
Expect early directive you suggest. Perhaps this is sensitive to particular
releases of Apache?
That's what I
Reposting the important information for Apache, without all the
diagnostics from the other part of the previous thread.
On 2013-03-01 at 17:03 -0500, Phil Pennock wrote:
We now have two separate issues affecting SKS (and GnuKS) keyservers
which have nginx or Apache in front of them, affecting
On 2013-03-02 at 22:21 -0500, Phil Pennock wrote:
So in fact, this is not normally biting Apache. I'll update the wiki
now.
John, Daniel: thanks for getting back to me and helping pin this down.
I've confirmed the new text is accurate. Got an Apache setup running,
passing onto the same
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Short version: bad interaction of GnuPG, cURL and Apache. Can probably
be worked around in Apache config, can definitely be worked around in
GnuPG code, should aim to get both done.
On 2013-02-28 at 10:01 -0800, Doug Barton wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
[ trimmed CC list, dropped gnupg-users people not directly relevant to
this post ]
On 2013-03-01 at 00:46 -0800, Doug Barton wrote:
Wow, what a thorough analysis, thanks Phil. :) FWIW, I did see those
Expect: headers you describe in my
Folks,
We now have two separate issues affecting SKS (and GnuKS) keyservers
which have nginx or Apache in front of them, affecting interop
compatibility with various versions of GnuPG (and other clients) as
deployed.
Even as changed clients roll out, we can expect to see clients which
have
On 2013-03-01 at 22:36 +, Daniel Austin wrote:
I've added the config to ports 80+11371 for pgpkeys.eu (using Apache
mod_proxy) and your example config from the wiki - all tests seem to
work for me, but please feel free to test for confidence.
If all works well, i'll duplicate the
So, it appears that nginx is not honouring:
proxy_ignore_client_abort on;
if the server was built with kqueue support (FreeBSD).
This might be a mistake somewhere in my configuration, but I don't think
so. A sanity check from others would be appreciated, thanks.
Temporarily turning on an
On 2013-02-27 at 21:08 +0100, Stephan Seitz wrote:
this is how my apache proxies requests to sks:
I see that the Server: header from SKS is being preserved in your setup;
is the Via header also automatically derived? Did you want to put in
anything just to say Apache?
I've put this into the
On 2013-02-27 at 10:57 +0100, Niels Laukens wrote:
Apologies for cross-posting to both mailing lists, but since I got
replies via both ways I feel this is the easiest way to sync them.
Current status: Kristian and I have debugged and he found the core
issue. If I load down my server, we can
Daniel referring to the reverse proxy stuff as a best practice nudged me
to take another look at the peering wiki page.
I've emphasised the current stance of folks that this is a best
practice, as backed by Daniel's stance, the impact of not doing so, and
the sheer number of servers on
On 2013-02-26 at 11:16 +0100, Niels Laukens wrote:
I'm having trouble getting keys of the pools on sks-keyservers.net. I've
just retried with the suggested debug-option with following result:
Okay, I ran:
unbound-control local_data hkps.pool.sks-keyservers.net. A 84.215.15.221
to talk to the
On 2013-02-21 at 15:22 -0300, Rafael wrote:
Is there a way I can disable the receiving of keys? The idea is people only
can search for public keys and when they want to add one they send it to
our admin and he puts it into the server.
What are you trying to achieve?
Based on your description,
On 2013-02-13 at 08:37 -0400, Jason Harris wrote:
On Wed, Feb 13, 2013 at 01:06:40AM -0500, Phil Pennock wrote:
Does anyone have any figures for the load caused by significant
differences in the numbers of keys had by two keyservers and how quickly
SKS stops being able to cope efficiently
Hey folks,
Does anyone have any figures for the load caused by significant
differences in the numbers of keys had by two keyservers and how quickly
SKS stops being able to cope efficiently?
A couple of my peers are 100K keys behind, so I've temporarily
de-peered from them and let them know, and
On 2013-01-25 at 18:34 +0100, Petru Ghita wrote:
Something else... On the proxy I *do* require a hostname in order to
make the redirect, but since the server is not in the pool, and since it
should only be called by it's full name as in keyserver.sincer.us or by
it's IP address, it really
On 2013-01-24 at 22:44 -0600, Casey Marshall wrote:
Hockeypuck 0.8.1 supports the PKS mail protocol. My server at
http://keyserver.gazzang.net can receive keys sent to
pgp-public-k...@keyserver.gazzang.net. Peers would be most welcome.
Added:
http://sks.spodhuis.org:11371/pks/lookup?op=stats
On 2012-06-11 at 21:49 -0400, Phil Pennock wrote:
Anyone else here using Google+ or Twitter?
I'm thinking of creating a keyserver operator circle list, both set
to be public.
In a follow-up to that post, I described some of the problems with
Google+ as it was then.
More recently, Google
On 2012-12-05 at 23:32 -0500, David Shaw wrote:
It's working, it's just misleading since the SRV replacement happens
after the debug logging so the actual URL that is hit is not the one
that is being logged. If you look at netstat, you can see it's
connecting to the right port.
Sorry for the
, then the expectation is
that you'll be in any pools anyone feels like adding.
(The expectation: okay, my understanding of the woolly view of an
ad-hoc group of people who haven't explicitly said this, AFAIK)
On 2012-12-04 at 16:45 +0400, Kristian Fiskerstrand wrote:
On 12/04/2012 01:21 PM, Phil Pennock wrote
On 2012-12-02 at 10:23 -0500, David Shaw wrote:
On Oct 6, 2012, at 10:20 PM, Phil Pennock sks-devel-p...@spodhuis.org wrote:
GnuPG folks (since this is cross-posted, if my mail makes it through):
there is a bug in GnuPG's SRV handling, I've identified where I think
it is, it's
is
http://keytest.spodhuis.org:11371/pks/lookup?op=getoptions=mrsearch=0x403043153903637F;
* HTTP auth is null
* HTTP method is GET
gpg: key 0x403043153903637F: Phil Pennock phil.penn...@globnix.org not
changed
gpg: Total number processed: 1
gpg: unchanged: 1
8
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-11-19 at 18:12 -0500, Philippe Gauthier wrote:
On 2012-11-18 23:55, Phil Pennock wrote:
The hostname in DNS now has an A record too, but the recon port is
not open on IPv4. This isn't going to work too well.
Good point. I moved
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-11-19 at 18:12 -0500, Philippe Gauthier wrote:
On 2012-11-18 23:55, Phil Pennock wrote:
The hostname in DNS now has an A record too, but the recon port is
not open on IPv4. This isn't going to work too well.
Good point. I moved
On 2012-11-12 at 11:52 -0500, Philippe Gauthier wrote:
This keyserver has been populated with a recent dump. There is an
important limitation that this host can only be accessed over IPv6 (it
has access to the IPv4 world, but though NAT). If this is not a problem
for some servers, I would
cut here 8--
sks-peer.spodhuis.org 11370 # Phil Pennock keyser...@spodhuis.org 0x3903637F
- 8 cut here 8--
- -Phil
-BEGIN PGP SIGNATURE-
iEYEAREDAAYFAlCh2V0ACgkQQDBDFTkDY39f0wCghgUYQdCTmAow7FwiD7787Yw9
On 2012-11-06 at 18:18 +, Ronny Wagner wrote:
I have a new keyserver running and would like to peer with other
servers. Please add me to your 'membership' file with the following
entry and provide your details in return so I can do the same:
SKS does not efficiently manage synchronisation
What do folks think of the idea of having sks dump also create a file
called [prefix]keycount.txt ?
That way, folks who make dumps available will have a really easy way to
also make a count of the keys available; depending on how they set up
the dumping, it might even happen automatically with no
I don't think anyone's using the keyserver pools I run, since they've
always been experimental; AFAIK, only Kristian has ever really looked
at them.
I finally got sufficiently fed up with the state of the Python I had for
the stats daemon (WSGI app), the memory usage, the performance, etc, and
On 2012-11-04 at 15:53 -0500, Phil Pennock wrote:
I finally got sufficiently fed up with the state of the Python I had for
the stats daemon (WSGI app), the memory usage, the performance, etc, and
got around to rewriting to app as a daemon in Golang. This has
reclaimed about 1/2GB of RAM
On 2012-10-25 at 12:42 -0700, k clair wrote:
I can't find anywhere that this is documented: Is there a way to
get the machine-readable output of a search to return the 16-digit
keyid rather than the 8-digit keyid?
Not at present. It would require code changes, nothing too severe.
Here's
On 2012-10-25 at 15:50 -0500, John Clizbe wrote:
Kristian and I were discussing this exact item yesterday. From my reading of
[1], I think 16-digit key IDs should be returned in the mr index. I /think/
Kristian may also be thinking that way.
8 cut here
On 2012-10-08 at 19:44 +0200, Kristian Fiskerstrand wrote:
Ok, I think I'm getting closer to having a working setup for a CA here
using subjectAltNames for hkps.pool.sks-keyservers.net
The current CA cert is available at [0] and I only currently sign
https://keys.kfwebs.net:11375 and
On 2012-10-08 at 23:01 +0200, Kristian Fiskerstrand wrote:
That seems like another bug to add to the SRV port not being used for
SRV handling. Are you sending it over to gnupg-{users,devel}?
I just filed a bug:
https://bugs.g10code.com/gnupg/issue1447
I'll have to remove the SRV record for
On 2012-10-08 at 23:25 +0200, Kristian Fiskerstrand wrote:
On 10/08/2012 10:49 PM, Phil Pennock wrote:
Unfortunately, with an https: keyserver, GnuPG is sending a request for
/ instead of /pks/lookup?... :(
Btw, this is related to [0], the https:// scheme isn't intended to be
used
On 2012-10-06 at 11:12 +0200, Stephan Seitz wrote:
I'ld like to add ssl to my server, but prior I'm afraid I need a few
questions answered.
If I'm going to install a self-signed *.pool.sks-keyservers.net, that
CRT wouldn't have any reputation. As long as there's no additional trust
added
On 2012-10-06 at 22:20 -0400, Phil Pennock wrote:
So, there's a `port` and an `opt-port`; the SRV lookups set `opt-port`
but not `port`, while the URL given to curl uses `port`.
It seems like changing 537 to:
port = opt-port = newport
should fix it as a stop-gap.
bugs.g10code.com
On 2012-10-05 at 20:48 +0200, Kristian Fiskerstrand wrote:
Just to inform that I've added a new hkps subpool to the list of options.
Regular A and and SRV records are included for port 443 servers,
and a lookup is performed for _pgpkey-https._tcp on the individual
servers to determine
On 2012-09-05 at 20:37 -0400, Phil Pennock wrote:
On 2012-09-05 at 11:33 +0200, Andreas Thulin wrote:
I have just set up a new keyserver and would like to peer with other
servers.
Please add me to your 'membership' file with the following entry and
provide your details in return
On 2012-08-16 at 12:50 +0200, Stephan Seitz wrote:
finally, I managed to create dumps on a regular base without risking BDB
inconsistence (Thank's, John).
The keydumps are publically available and created every Thursday around
9 AM CET. I think that's UTC+2.
On 2012-08-10 at 00:45 -0400, Robert J. Hansen wrote:
John Clizbe and I have both had a problem recently with sks recon
crashing in a way that completely borks the PTree/ subdirectory. If
your sks recon process dies and, upon restarting it, you see this in the
log:
2012-08-10 00:38:56
On 2012-08-10 at 17:40 +0200, Kristian Fiskerstrand wrote:
Or there just is a change to other environmental factors, so limiting to
that might be a case of Post Hoc ergo Propter Hoc :)
I have word off-list from a GnuKS developer that they're not using my
clock resolution fixes but do see this
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, and
While I've used git/hg a bit, before today I hadn't dealt with creating
server-forked repos and issue pull requests.
That part of the process is clean and simple. But none of the docs I'm
finding describe what happens *next*, how do you clean up?
I know that for git-like models, and I assume
On 2012-07-26 at 09:40 -0400, Phil Benchoff wrote:
server {
listen ...
root /your/keyserver/web;
location /pks {
proxy_pass http://localhost:11371/pks;
add_header Via 1.1 keyserver.example.com;
}
}
I don't have a good setup to fully test this config, but at
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-06-25 at 15:38 +0100, Andy Ruddock wrote:
If the version number requirements for being in the keyserver pool is
greater than that provided in the repositories then the package may just
as well not be in the repositories at all.
No,
On 2012-06-14 at 02:27 +0200, someone wrote:
On Mon, 2012-06-11 at 21:49 -0400, Phil Pennock wrote:
I'm thinking of creating a keyserver operator circle list, both set
to be public.
Is this really a good idea? I mean I'd like to see a sks-operators
mailing list... and this list should
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
Kristian drew my attention to sks.spodhuis.org showing a last update of
May 25th.
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
On 2012-05-29 at 14:20 -0400, Jeffrey Johnson wrote:
Sure there's a way to use Berkeley DB without transactional logs.
[snip]
Okay, pedantically you're correct, but since I was trying to *just*
modify sksclient and not the server, most of what's possible with other
modes of operation is
On 2012-05-29 at 22:26 -0400, Jeffrey Johnson wrote:
The problem with VM timing was reported here: I'm still not
sure what the mechanism is (from what I think I know about
Berkeley DB, perhaps wrongly). There's also the chance that
tstamps as data change program flow: but that is application
On 2012-05-29 at 20:11 -0700, David Benfell wrote:
How many keyservers run NTP, BTW?
DisUnitedStates.com runs openntp. It turns out this is publicly
available (which is fine with me but I haven't checked that it is
associated with an appropriate tier).
OpenNTP is not disciplined enough to
?
-Phil
# HG changeset patch
# User Phil Pennock codeha...@spodhuis.org
# Date 1338350421 14400
# Node ID 5f5e3980e3b3590ac52745e67ff649c8dd9bd7ac
# Parent 8fcedf0ead3528b5cef8e42ece8168d82e75cbfc
Use unique timestamps for keydb
diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
On 2012-05-28 at 09:14 +0200, Kiss Gabor (Bitman) wrote:
BTW. What if a newsgroup called alt.gpg.keys was used as an alternate
channel aside gossip protocol to distribute keys? NNTP transfers zillions
of news articles within seconds from Buenos Aires to Tokyo. It is
quite reliable too.
You
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-05-26 at 17:35 -0700, David Benfell wrote:
Just for my own idle curiousity, if the complaint about google code's
hosting is that its pull request architecture is inferior, wouldn't
that be a criticism of mercurial itself?
Since we're
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-05-19 at 19:47 -0500, John Clizbe wrote:
Thanks to work by Kristian Fiskerstrand, Phil Pennock, and myself the
following changes are now available on the SKS trunk:
Fresh clone:
- 8 cut here 8
On 2012-05-14 at 09:57 +0200, Sebastian Urbach wrote:
Another exiting Debian Binary Replacement has been released, As usual
you can find it right here:
http://key-server.org/sks/
(1) In compliance with the GPL,
(2) as a contributor of code under the GPL license which has been
included in
On 2012-05-13 at 15:20 -0500, John Clizbe wrote:
So I'd restate Kristen's requirement as a server's peers need to have in their
membership file the name in the host's sksconf file, be that an A record or a
CNAME (or an entry in /etc/hosts). In actual practice, this is, as Kristen
described it,
On 2012-05-13 at 16:33 -0400, Phil Pennock wrote:
When I do reclaim the IPv4, I'll
probably split sks/sks-peer to two different IPv6 addresses and set up
appropriate packet-filtering on the v6 address, so that peering can
remain up even in the face of DoS
Gentlemen,
The SKS peering mesh is built upon trust; in no small part, because the
peering algorithm can cause load upon your peers. Recent events have
forced me to re-evaluate two of my peerings.
I have modified my memberships file, removing the following two lines:
-keyserver.ccc-hanau.de
On 2012-04-29 at 11:00 +0200, Stefano Rivera wrote:
keyserver.leg.uct.ac.za is in ZA, and your geoip service thinks so too:
;; ANSWER SECTION:
11.142.158.137.zz.countries.nerd.dk. 2100 IN TXT za
So not sure why you aren't seeing keyservers outside NA/EU.
Ah, of course. The version check,
I got around to adding region-based sub-pool entries in my experimental
playground SKS pool definition, with six regions (below); I'm only
actually seeing entries for North America and Europe, though.
I suspect that this is a geocoding failure, rather than *complete*
absence, but I wonder if
attached a patch, taken relative to Yaron's 1.1.3 merge,
implementing this. Plus a couple of related cleanups in HTTP error
response handling.
-Phil
# HG changeset patch
# User Phil Pennock codeha...@spodhuis.org
# Date 1334995596 25200
# Node ID 136777f56c79d257eec30ce603cc91cbaaaf08fd
# Parent
On 2012-04-11 at 01:40 -0500, John Clizbe wrote:
make dep
I just verified I was able to cause the same error by removing .depend.
It worked normally again after ' make dep'.
That worked, thank you.
___
Sks-devel mailing list
Sks-devel@nongnu.org
On 2012-04-05 at 17:32 -0400, Daniel Kahn Gillmor wrote:
On Wed, 4 Apr 2012 18:02:49 -0600, Ryan ad...@nayr.net wrote:
I had problems reverse proxying 11371 behind a load balancer; would
break other sks servers fetching keys.
Yep, this seems to be the case.
I used strace to capture such
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-03-25 at 03:01 -0500, John Clizbe wrote:
Phil Pennock wrote:
My best guess, which is *only* a guess and I haven't had time to
investigate and so I didn't provide it on the page, is that the
timestamp is being put into a key
Okay, we appear to have two people for whom the TSC clocksource in the
kernel fixes PTree corruption, so I've currently got this in the wiki:
Virtual Machine issues
There are some issues with clock-keeping mechanisms in some virtual
machines (VMs) affecting the Berkeley DB used for PTrees;
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
On 2012-03-19 at 21:11 +0100, Kristian Fiskerstrand wrote:
Here you go!
Added ha.pool. The HTTP Server code is available at e.g.
http://sks-keyservers.net/status/info/keys.kfwebs.net . Atm I'm only
including nginx servers in the subset.
The http://code.google.com/p/sks-keyserver/wiki/Peering page now
suggests using an HTTP reverse proxy and provides an example
configuration based on DKG's configuration.
I've also added:
http://code.google.com/p/sks-keyserver/wiki/KeydumpSources
which takes the list from
On 2012-01-25 at 13:34 -0800, John Webster wrote:
I was wondering, should we be sending status messages to this list?
Opinions differ; evidence: people do send status messages.
Frankly, I think not, unless you're off-line and not coming back.
SKS handles down hosts gracefully. The DNS pool
On 2011-10-27 at 06:26 +0200, Kiss Gabor (Bitman) wrote:
The Right Thing would probably be anycast but I doubt any of us is ready
to go to the trouble of setting up such a beast. In the mean time we
Anycast would be great.
Anycast is of most use when you are, for some reason, constrained
On 2011-09-19 at 09:05 +0200, Kiss Gabor (Bitman) wrote:
Searching alternate mailsync peer in the list archive is
not possible because archive sites hide e-mail addresses. :-(
So I also have to ask: where to forward e-mail updates?
Sorry for the noise.
I emailed and got permission from
On 2011-09-11 at 11:12 +0200, Jens Leinenbach wrote:
1. A user visited http://pool.sks-keyservers.net:80/
2. A random SKS server answered with its SKS index page on port 80 by
accident.
3. But when he sent his key to the server, the IP for the domain
pool.sks-keyservers.net changed in the
Folks,
After seeing Samir's suggested index.html page, I decided to make a few
updates to my own. It's a nasty competitive streak that sometimes comes
to the fore.
http://sks.spodhuis.org/
The page was already HTML5, but now, most significantly, if using a
browser which supports dragdrop with
On 2011-08-29 at 02:40 -0400, Robert J. Hansen wrote:
Although I don't mean to dissuade anyone from following their muse, why
HTML5? Wouldn't 401+CSS be better supported by existing browsers? Or
does 5 add some vital capability that I'm just completely missing?
HTML (done right) downgrades
On 2011-08-29 at 09:45 +0200, Sascha Silbe wrote:
Excerpts from Phil Pennock's message of Mon Aug 29 08:55:01 +0200 2011:
HTML (done right) downgrades gracefully. If anyone using an older
browser experiences problems with http://sks.spodhuis.org/ then please
report it to me as a bug.
On 2011-06-17 at 04:06 +1000, Matthew Palmer wrote:
On that topic, it'd be really handy if the stats page of a server had a
contact e-mail address listed in there... (real, honest-to-goodness, legit
hostnames would also be nice).
No, web-pages get scraped by spammers and the email addresses
On 2011-06-01 at 09:39 -0400, Robert J. Hansen wrote:
At risk of pointing out the obvious, you've just added to the
keyserver network a way to delete keys and keep them from getting
re-entered into the DB.
Not quite: it's added a way for each individual keyserver operator to
delete keys from
On 2011-05-26 at 17:24 +0100, Xian Stannard wrote:
I've built a script to look through ASCII armored message and show
information from it. It works best with public keys.
For those of you inquisitive of the information messages:
http://sks.xianic.net/extras/dissect.php
Always good to have
On 2011-05-21 at 12:30 -0500, John Clizbe wrote:
There has never been a set format requirement for the email seeking peers.
There's been a suggestion or two, but I don't recall a vote.
Part of that may be my fault: when I wrote the
http://code.google.com/p/sks-keyserver/wiki/Peering document, I
On 2011-05-15 at 12:10 -0700, Robert Hinson wrote:
I am wondering who this one is:
2011-05-15 14:04:29 Get request: ADDR_INET [94.142.240.6]:59559 =
/pks/lookup?op=stats
reverses to:
6.240.142.94.in-addr.arpa domain name pointer causeway.spodhuis.org.
As Arnold noted, that's me. That's
On 2011-04-09 at 10:33 +0100, Tiago Faria wrote:
I'm having a hard time trying to understand why SKS daemons don't start
after I enter my IPv6 addresses on the configuration file.
At a console, as the SKS run-time user, start it with:
-debug -debuglevel 9 -stdoutlog
Eg, something like:
#
On 2011-03-29 at 12:14 -0400, Daniel Kahn Gillmor wrote:
I don't use seahorse regularly, but i recently convinced them to replace
(old, broken, non-syncing) pgp.mit.edu with a pointer to
pool.sks-keyservers.net:
Uhm, the pgp.mit.edu which is running SKS and syncing with 10 peers?
-Phil
On 2011-02-20 at 10:20 -0800, David Benfell wrote:
To borrow the boilerplate from http://www.keysigning.org/sks/ :
I have a new keyserver running and would like to peer with other
servers. Please add me to your 'membership' file with the following
entry and provide your details in return so
On 2011-02-20 at 23:35 -0800, David Benfell wrote:
The Debian start script seems to be broken now. It wasn't earlier.
It's just silently failing, with no log entries that I know how to
find.
File ownership?
___
Sks-devel mailing list
On 2010-12-29 at 22:44 +0100, Christoph Anton Mitterer wrote:
On Tue, 2010-12-28 at 20:56 +, Kim Minh Kaplan wrote:
https://datatracker.ietf.org/doc/draft-shaw-openpgp-hkp/
SKS does not conform to it in several places,... I've opened issues
for the respective cases at google code some
On 2010-12-28 at 01:11 -0500, Phil Pennock wrote:
Note that the hostnames used are those configured into the sks instances
as their own hostname, so not all are valid in public DNS; antix,
basket and booboo come to mind. The default server is the one
running on the host the JS was loaded from
101 - 200 of 247 matches
Mail list logo
