Reverse-Proxy Test Request

Greetings All,

keys.riverwillow.net.au has just had some long-overdue TLC.  I have
upgraded from 1.1.3 to 1.1.4 (with a complete dump and reload) and have
moved the db server behind a Squid server on the same host.  It looks to
me like everything is working as it should but, given some of the
reverse-proxy corner-case breakage reports, I'd be grateful for reports
of anything I may have missed.

If anyone has a test suite they use for this purpose, I'd be grateful if
you would point it at our server and send me the results off-list.  If
all looks good to the community, I'll post my Squid proxy config so that
it can be added to the wiki.

Thank you.

--

-- 
John Marshall

Greetings All,

keys.riverwillow.net.au has just had some long-overdue TLC.  I have
upgraded from 1.1.3 to 1.1.4 (with a complete dump and reload) and have
moved the db server behind a Squid server on the same host.  It looks to
me like everything is working as it should but, given some of the
reverse-proxy corner-case breakage reports, I'd be grateful for reports
of anything I may have missed.

If anyone has a test suite they use for this purpose, I'd be grateful if

keyserver.siccegge.de IP change

Hi all!

  Unfortunately keyserver.siccegge.de lost it's static IPv4
configuration. DNS has been set up to follow the actually used IP
addresses (hopefully visible soon on a Nameserver near you). I will soon
add a (static) IPv6 address again (allocated from
2001:a60:f01c::/48). If you are peering with me right now and can not
handle changing IP addresses please inform me!

    Christoph

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

Hi all!

  Unfortunately keyserver.siccegge.de lost it's static IPv4
configuration. DNS has been set up to follow the actually used IP
addresses (hopefully visible soon on a Nameserver near you). I will soon
add a (static) IPv6 address again (allocated from
2001:a60:f01c::/48). If you are peering with me right now and can not
handle changing IP addresses please inform me!

    Christoph

--

-- 
9FED 5C6C E206 B70A 5857  70CA 9655 22B9 D49A E731
Debian Developer | Lisp Hacker | CaCert Assurer

nginx: security update

http://nginx.org/ -- security update, released today, affects versions
1.3.9 to 1.4.0.

Simple patch:
  http://nginx.org/download/patch.2013.chunked.txt

In related news: there was a brief interruption in availability of
sks.spodhuis.org.  FreeBSD Ports moved 1.4.x from www/nginx-devel to
www/nginx and there a CONFLICTS rules, so I couldn't build and upgrade
in place (even with `portupgrade -o www/nginx nginx-devel`), and since
this is a personal colo box with no build infrastructure, I ended up
just stopping/removing nginx-devel and then building nginx in its place.

Back now.

-Phil

Filtering specific keys

Greetings,

I would like to see the option in SKS to filter out (hide) PGP keys with
specific keyids and email addresses locally; e.g. using a blacklist
taken from a local configuration file. Since SKS already has display
filters that hide some broken keys, I think it shouldn't be very hard to
implement this.

The reason for this is to be able to comply with notice-and-take-down
orders. We talked about this two years ago when Pramberger's server was
forced offline by an Austrian user, but similar cases are likely -
especially with regard to images included in some PGP keys. At the
moment a user in France is contacting keyserver owners to get keys taken
offline that have been uploaded by others, using his name and email
address.

Although it would impact consistency among keyservers, hiding keys seems
a better solution than removing them altogether, or having some servers
taken offline because they are unable to comply with local legislation.
Removing keys globally may not be necessary in many cases, as laws
regarding privacy, trademarks, offensive pictures etc. are very
different in different countries.

Regards,
Johan

Greetings,

I would like to see the option in SKS to filter out (hide) PGP keys with

DisUnitedStates.com should be back up

Hi all,

It's running anyway. 

And I now *mostly* have mail working, so if anyone wants to make any
changes relative to disunitedstates.com -- peer requests (add or
drop), or if anyone sees any problems, now's the time.

The server is located in Munich: statistics are at
http://disunitedstates.com:11371/pks/lookup?op=stats

My membership file entry would look something like:
disunitedstates.com 11370 #David Benfell <benfell@...>
0xEE3DBE12
(sorry for the line break)

Disunitedstates.com: DB_AUTO_COMMIT may not be specified in non-transactional environment on build

Hi all,

Ick. This is proving more difficult than I expected.

Trying to dump the database on the old server yielded some kind of
database error, with the suggestion to run recovery. I couldn't find
how to do a recovery, so I just copied the latest dump from
prato.linux.it instead.

Now trying to build the database, choosing '2' for the faster sks, I
get 'DB_AUTO_COMMIT may not be specified in non-transactional
environment'. I'm not seeing anything useful about this error on the web.

Now what? By the way, please cc at dbenfell@... I still haven't
got mail sorted out yet.

Thanks!

disunitedstates.com moving -- downtime

Hi all,

DisUnitedStates.com is moving from a Linode VPS in Atlanta to a
Contabo dedicated server in Munich. The good news is that this
*should* be a much more capable system and improve service.

The bad news is that Contabo does not yet offer IPv6, so
DisUnitedStates.com will be dropping from the IPv6 pool.

I'm having some issues getting the DNS moved, so there may be a delay,
but I will be taking down the old sks server shortly and dumping the
database to move over to the new server.

The new IP address is 91.205.174.231. The old ones were 173.230.137.73
and 2600:3c02::02:7004.

I'm also having trouble whipping thunderbird into shape with the new
server, so I may not see any requests for changes in membership right
away (it isn't seeing any subfolders in INBOX).

Thanks!

stuck in "Reconciliation attempt from <ADDR_INET [XXXXX]:33091> while gossip disabled. Ignoring."

I realized today that zimmermann.mayfirst.org (aka keys.mayfirst.org)
had dropped out of the main SKS pool. [0]
https://sks-keyservers.net/status/ suggested it was > 4K keys behind
everyone else.

Looking in the recon logs, i saw at least five days of:

   Reconciliation attempt from <ADDR_INET [XXXXX]:33091> while gossip disabled. Ignoring.

but my logs didn't go far enough back to indicate why gossip was
disabled.

keys.mayfirst.org is running SKS 1.1.3.

Restarting the server seems to have reset the ability to gossip, and
it's now catching up, but i am curious to understand the logic here.  Is
it possible that the failure of a peer i'm currently trying to reconcile
with could cause SKS to stay in a gossip_disabled state?

in recoverList.ml, i see this definition:

  let gossip_disabled () = 
    not (Queue.is_empty recover_list) || !gossip_disabled_var

gossip_disabled_var is set at the tail of recoverList.ml within a "let
update_recover_list" stanza (which i think is a sort of function
definition, but i don't know ocaml well enough to get the terminology
right; corrections welcome!)

and gossip_enabled_var is only ever cleared inside a "let rec

Server maintenance sks-keyservers.net

Dear list,

Just as an FYI there might be some disruptions to the availability of
the website of sks-keyservers.net over the weekend (30 March - 1
April) as I will finally get around to upgrading the hardware of the
server.

At the same time the pool might not update at the regular scheduled
intervals, however it should not otherwise affect the availability of
the pool, and the downtime is expected to be minumum.

Thanks to the donators[1] that have contributed to the funding of the
server upgrade.

[1] A list of those that have checked the please list button is
available at http://www.kfwebs.net/donations.php

--

-- 
----------------------------
Kristian Fiskerstrand
Twitter:  <at> krifisk
----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
----------------------------
Cogito ergo sum
I think, therefore I am

Upgrading to 1.1.3 Through Debian Backports

All,

I would like to upgrade my sks on Debian Squeeze from 1.1.1 to 1.1.3
using Debian backports. Is there anything of which I need to be aware
when making this upgrade?

Thanks,
Patrick

All,

I would like to upgrade my sks on Debian Squeeze from 1.1.1 to 1.1.3
using Debian backports. Is there anything of which I need to be aware
when making this upgrade?

Thanks,
Patrick

Re: seeking peers for key.s-l-c.biz

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 25.03.2013 20:57, schrieb Andrew Alderwick:
> Dear Simon,
>
> Thanks for adding me!
>
> I had a little trouble getting a connection to your server. Despite
your email address, I took your hostname in your original email as given:
>
> On Mon, Mar 25, 2013 at 12:50:33PM +0100, Simon Lange wrote:
>> keys.slc.biz 11370 # Simon Lange <slange@...> 0xBDD503BE
>
> I think that should be keys.s-l-c.biz 
*gosh* you damn right... mistype by me!
should be keys.s-l-c.biz not key.slc.biz ... m)

- -- 
________________________________________________________
Simon Lange Consulting  - Gaudystr. 6  - DE-10437 Berlin
Telefon: +49(0)30/89757206 Mobil: +49(0)151/22640160
- ----------------------------------------http://s-l-c.biz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (MingW32)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBAgAGBQJRUMj1AAoJELCfvQa91QO+T2gH/RDbEO5IYi87iQDZTrJBdkfF
47zWx72xRpc0Tsao8SnapWbRf5MxQTg4E++YQaU+qudv4KdnzekKWyhJG2kZYdft