stepping away from sks

Hi folks-- I no longer think that SKS is a project i can contribute to responsibly, so i'm stepping away from it. I'll be taking down the sks instance on zimmermann.mayfirst.org (https://support.mayfirst.org/ticket/14873), so if you have that in your peers file, you should probably remove it.

Re: [Sks-devel] [openpgp] Modelling an abuse-resistant OpenPGP keyserver

On Mon 2019-04-15 13:16:07 -0400, Daniel Kahn Gillmor wrote: > I've labeled the abuse-detection action you're describing as "identity > monitoring" in draft -03. […] > This is a useful insight, and i've tried to document it in -03 as well. > I welcome text to improve it. O

[Sks-devel] Modelling an abuse-resistant OpenPGP keyserver

kg-openpgp-abuse-resistant-keystore-00 date: 2019-04-04 category: info ipr: trust200902 area: int workgroup: openpgp keyword: Internet-Draft stand_alone: yes pi: [toc, sortrefs, symrefs] author: - ins: D. K. Gillmor name: Daniel Kahn Gillmor org: American Civil Liberties Union s

Re: [Sks-devel] Excessive use of /var/lib/sks/DB/log.*

On Fri 2019-02-08 16:48:16 -0600, Gunnar Wolf wrote: > Hey dkg! hi Gunnar! :) > With hindsight, that was my mistake - When I rebuilt my server > about a month ago (after a DB corruption), I decided to keep my > installation and just delete /var/lib/sks/DB/*, rebuilding from > dumps. Of course, I

Re: [Sks-devel] Excessive use of /var/lib/sks/DB/log.*

On Wed 2019-02-06 20:27:28 -0800, Todd Fleisher wrote: > This sounds like you are missing the recommended DB_CONFIG values to > prevent your server from holding into those log files when an issue is > encountered. As I recall, the fix is to start over from scratch and > rebuild after first putting

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

On Fri 2019-02-08 20:44:33 +, Andrew Gallagher wrote: > Parse the syslogs of an old style SKS server, fetch any updated > packets, filter them and submit to the new server. ah yes, the SMOP (it's a "Simple Matter of Programming") argument :) > Sync from the old network to the new one only

Re: [Sks-devel] "SKS is effectively running as end-of-life software at this point"?

On Thu 2019-02-07 23:15:18 +0100, Kristian Fiskerstrand wrote: > The current discussions we're having (e.g during OpenPGP email summit in > brussels in october and lately on FOSDEM last weekend) is eventually not > storing UIDs at all on the keyservers, but require the user to do key > discovery

Re: [Sks-devel] SKS apocalypse mitigation

On Fri 2018-03-23 11:10:49 +, Andrew Gallagher wrote: > Updating the sets on each side is outside the scope of the recon > algorithm, and in SKS it proceeds by a sequence of client pull requests > to the remote server. This is important, because it opens a way to > implement object blacklists

Re: [Sks-devel] TLS 1.3 and HKPS pool

On Mon 2018-03-19 17:24:07 -0400, Phil Pennock wrote: > On 2018-03-19 at 22:14 +0100, Kristian Fiskerstrand wrote: >> On 03/19/2018 10:08 PM, Phil Pennock wrote: >> > Do we care? >> >> I'm tempted to say no.. I also agree that we do not care, and should issue no guidance that encourages servers

Re: [Sks-devel] Out of the pool

On Tue 2018-01-30 14:06:45 +0100, Paul Fontela wrote: > 2 - If we all add the task of cron "00 * * * * pkill -USR2 sks || exit > 1" in our servers, it would be beneficial to keep more updated > statistics in sks-keyservers.net/status/ that if it is only done every > 24 hours ?. due to sks's

Re: [Sks-devel] Debian asks package and default paths

On Tue 2018-01-23 10:51:54 +0100, Alain Wolf wrote: > I would try to change desired filepaths in > debian/patches/0001-use-debian-fhs.patch Hi there-- I'm one of the current maintainers of the debian package. this patch is intended to put sks in compliance with the filesystem hierarchy.

Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]

On Sun 2018-01-14 18:23:59 +, Heiko Richter wrote: > hardcoding a root certificate into a program has > *never* been any kind of accepted security system. pinning certificates (either end-entity or further up the chain) is considered a good practice in a design where there is an expected

Re: [Sks-devel] Unde(r)served HKPS [was: Underserved areas?]

On Thu 2018-01-11 22:30:54 +0100, Alain Wolf wrote: > Maybe something along the line of ... sounds like you're (roughly) reinventing some sort of acme protocol. if we're going to do that, then we should just encourage kristian to use acme directly. imho, having a dedicated CA for this

[Sks-devel] Raising the floor for the pool to SKS version 1.1.6 [was: Re: Importing ed25519 subkeys from SKS < 1.1.6]

(adding sks-devel to this thread since it discussies changing the minimum bar for the pool) On Wed 2017-09-06 23:46:59 +0200, Kristian Fiskerstrand wrote: > On 09/06/2017 11:33 PM, Werner Koch wrote: > >> including all of the RSA and DSA subkeys. But not the original >> requested ed25519 key.

Re: [Sks-devel] hg workflow pointers

On Tue 2017-08-08 15:27:46 +0200, Kristian Fiskerstrand wrote: > (i) Should we use git for revision control instead of mercurial? this was the question i wanted to trigger -- i'm happy we're having the discussion. > (ii)(A) Should we continue to use bitbucket (it also supports git so > not

Re: [Sks-devel] hg workflow pointers

On Thu 2017-08-10 00:49:31 -0400, Jason Harris wrote: > I prefer Mercurial - much lighter I'm not sure what "lighter" means, but it's surely not about speed -- i can clone a git repo the size of sks in a fraction of the time it takes me to hg clone the sks repo. > and much less risk of ruining

[Sks-devel] hg workflow pointers

hey folks-- i'm comfortable with git. i'm even comfortable on github, gitlab, and other similar platforms. I'm not as comfortable with mercurial (hg), or with bitbucket's hg interface, but i think i'm educable. This is a request for pointers for simple workflow help. i find that every time i

[Sks-devel] HTTP reverse proxy failures at pgp.mit.edu

Hey all-- If you look at https://pgp.mit.edu/pks/lookup?op=get=0xF2AD85AC1E42B367 it appears that there's some sort of proxy failure. the end of it looks like: --- VcZqMYLvC976Pel/3NSXRKBrgVVWvoiEvH/Zaxxy1RjpRBWomzGInAQQAQIABgUCVu5/IwAK

Re: [Sks-devel] ECC HTTPS certs for HKPS

On Fri 2017-03-31 16:40:25 -0500, Phil Pennock wrote: > Is anyone interested in testing client/tooling interop with an HKP > keyserver (SKS) which has ECC keys/certs in front of it? I need to > renew my sks-keyservers cert within the next month and when I asked > Kristian last year, dual-stack

Re: [Sks-devel] nokeyserver annotation

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. The two "attack" scenarios i can imagine

[Sks-devel] nokeyserver annotation

hi folks-- as you know, 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:

Re: [Sks-devel] SKS logging to syslog using 1.1.6-2~bpo8+1 from debian-packports

On Mon 2016-12-05 09:37:13 -0500, Pete Stephenson wrote: > I don't mind having certain behavior be the default -- and, as you > say, there are good reasons for having that be the default -- but > user-added entries in the config file should take precedence. hm, i think i agree with you there, but

Re: [Sks-devel] Making keys unusable with spamming similar uids

On Fri 2016-09-16 16:17:41 -0400, Brian Minton wrote: > One possibility would be to have the keyserver sort by the time the > key was first seen. That way, there'd be a slightly lower chance of > getting an impostor's key. Going by the creation date is not very > useful, since impostors could

[Sks-devel] debian package tracking of the bdb version [was: Re: Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released]

Hi William-- On Sat 2016-09-03 10:10:13 -0400, William Hay wrote: > 1.Thanks for the nice jessie-backports package. you're welcome! > 2.AFAICT the package postinst performs a backup unless the file > /var/lib/sks/berkeley_db.active is present and the contents match those > of

Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released

On Wed 2016-08-31 15:44:20 -0400, Jeremy T. Bouse wrote: > Is the package still forcing the backup and re-import on upgrade? I > know that is what took one of my servers out when I upgraded as they > don't have the space to do so. I'd rather just blow away the DB and > let my SaltStack deployment

Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released

Hi William-- On Wed 2016-08-31 13:26:24 -0400, William Hay wrote: > On Mon, Aug 08, 2016 at 03:45:12PM -0400, Daniel Kahn Gillmor wrote: >> I've prepared a jessie-backports package that i'm running on >> zimmermann.mayfirst.org as well. As soon as 1.1.6-1 makes it into >&g

Re: [Sks-devel] [OT] Any Tor experts here?

Hi Danny-- On Mon 2016-08-29 15:00:50 -0400, Danny Horne wrote: > I've just spent several hours trying to get Tor running as a service > (under systemd) for sks. > > Here's some relevant logs (the directories exist under toranon user / > group) - > > Aug 29 18:46:16 marconi tor: Aug 29

Re: [Sks-devel] Debian Jessie package for sks-1.1.6 was: [Announcement] SKS 1.1.6 Released

Hi all-- On Mon 2016-08-08 14:45:15 -0400, George K. wrote: > On Sun, 07 Aug 2016 17:17:03 +0200 > Christoph Egger wrote: > >> Gabor Kiss writes: >> >> > Out of curiosity, is there any Debian-type repository one can >> >> > use to install

Re: [Sks-devel] [Announcement] SKS 1.1.6 Released

Thanks for the clarifications, Kristian! followup below about bitbucket: On Mon 2016-08-08 10:16:38 -0400, Kristian Fiskerstrand wrote: >> https://bitbucket.org/skskeyserver/sks-keyserver/downloads >> >> has some very strange text in it: >> >> >> sks-1.1.6.tgz >>

Re: [Sks-devel] [Announcement] SKS 1.1.6 Released

On Sun 2016-08-07 10:40:08 -0400, Kristian Fiskerstrand wrote: > We are pleased to announce the availability of a new stable SKS > release: Version 1.1.6. great, thanks! > Note when upgrading from earlier versions of SKS > > The default values for pagesize settings changed

Re: [Sks-devel] Pools & HSTS header

On Fri 2016-06-03 10:49:57 -0400, Christoph Egger wrote: > William Hay writes: >> On Thu, May 26, 2016 at 12:47:57AM +0200, Valentin Sundermann wrote: >>> Hi, >>> >>> I enforce HTTPS on all my domains by sending the HSTS header to my >>> visitors. HSTS forces the browser to use

Re: [Sks-devel] Oh, Jeeez...!

On Fri 2016-05-27 07:54:50 -0400, Pascal Levasseur wrote: > Suppose we add a POW data to the PGP key data transaction request > > We can use the number of 0 in the 160-bit SHA-1 hash as the level of > complexity indicator. > > The servers who receive a request from an user software to add a key

Re: [Sks-devel] memory leak: solved

following up from a rather old thread... On Thu 2015-04-30 14:52:48 -0400, Tobias Mueller wrote: > On Fr, 2015-04-10 at 17:18 -0400, Daniel Kahn Gillmor wrote: >> I consider this a bug in SKS, if it can overconsume RAM on the basis >> of one misbehaving or rejecting peer. >>

Re: [Sks-devel] trouble building most recent version of sks-keyserver from hg

horrible. (and if it's OK, feel free to apply it upstream!) --dkg From: Daniel Kahn Gillmor <d...@fifthhorseman.net> Date: Fri, 6 May 2016 18:52:17 -0400 Subject: Avoid deprecated ocaml newer versions of ocaml explicitly deprecate: * String.create in favor of Bytes.create * Strin

Re: [Sks-devel] Bug#823394: sks: Exception raised when searching for specific key

[ adding the upstream sks-devel mailing list to this thread] over on https://bugs.debian.org/823394, Joost wrote: On Wed 2016-05-04 04:44:06 -0400, Joost van Baal-Ilić wrote: > This query http://pgp.surfnet.nl/pks/lookup?search=satoshi=index gives > > Error handling request > Error handling

Re: [Sks-devel] Tor hidden service - what's the rationale?

On Fri 2015-11-13 20:36:40 -0500, Alain Wolf wrote: > On 14.11.2015 at 01:23, Christoph Anton Mitterer wrote: >> On Sat, 2015-11-14 at 01:15 +0100, Hendrik Grewe wrote: >>> I would imagine not leaving the tor network through an exit is the >>> benefit. >> And what should be the benefit of that? >

Re: [Sks-devel] Tor hidden service /onionbalance for hkp

On Fri 2015-11-13 06:08:37 -0500, Kristian Fiskerstrand wrote: > On 11/13/2015 11:27 AM, Christoph Egger wrote: >> Is there some documentation published on what is needed on the side >> of a keyserver operator? I'd really like to get my keyserver added >> there (next week sounds good for doing the

[Sks-devel] using full fingerprint instead of keyid for internal links

hey all-- i've noticed that sks search= pages produce internal links for get= pages that use key IDs instead of full fingerprints. I think that key IDs are a bad idea pretty much anywhere they show up [0]. Would anyone have any objection to producing internal links that use full fingerprints

Re: [Sks-devel] Seemingly corrupted DB, not syncing

On Thu 2015-08-06 12:03:28 -0400, Gunnar Wolf wrote: Gunnar Wolf dijo [Thu, Aug 06, 2015 at 10:50:59AM -0500]: OK, this *seems* to have worked: After removing and creating a new, empty /var/lib/sks/PTree directory, I started sks, and am getting several such log messages: Umh, spoke too fast:

Re: [Sks-devel] Proposal: Start verifying self-signatures

Thanks for the followup, Yaron-- On Tue 2015-05-19 18:18:44 -0400, Yaron Minsky wrote: Let's think about a simpler question: deletion. I actually think after-the-fact deletion is a much harder question than setting up filters based on some technical/discoverable aspect of OpenPGP packets.

Re: [Sks-devel] Proposal: Start verifying self-signatures

On Tue 2015-05-19 15:55:34 -0400, Daniel Roesler wrote: On Tue, May 19, 2015 at 4:04 AM, ma...@wk3.org ma...@wk3.org wrote: But there was also the question on how to deal with the situation on a more conceptual level and I don't know what this would entail in a technical sense, Here's a

Re: [Sks-devel] normalbuild segfaults

On Thu 2015-05-07 00:14:02 -0400, Gunnar Wolf wrote: FWIW, Debian 7 ships with SKS 1.1.3, while Debian 8 has 1.1.5. I understand the difference is quite significative, and if you don't have a specific reason to use the older version, you should use the one provided with Debian 8. I tend to

Re: [Sks-devel] memory leak: solved

On Fri 2015-04-10 03:32:20 -0400, Kiss Gabor (Bitman) wrote: sks 1.1.5+ requires round about 300MB in main memory on key.cccmz.de and key.ip6.li. May be there is a problem, when haproxy is used in tcp mode to proxy port 11370. key.ip6.li did not have problems, but a test system has also

Re: [Sks-devel] Analyzing key server data

On Sun 2015-03-22 10:33:01 -0500, Daniel Roesler wrote: I was under the impression that SKS verified signature packets both during upload and during gossip. SKS does no cryptographic verification. :( Even if it were to start doing verification, it's not clear how that would work with

Re: [Sks-devel] recon stops: 2015-02-11 07:09:48 Raising Sys.Break -- PTree may be corrupted: Failure(remove_from_node: attempt to delete non-existant element from prefix tree)

On Fri 2015-02-13 12:28:25 -0500, Kristian Fiskerstrand wrote: The startup-scripts provided by whichever sane distribution should fix this anyways to be a non-issue. From the Gentoo /etc/init.d/sks-db: start_pre() { checkpath --owner sks:sks --directory \ ${SKS_DIR}

Re: [Sks-devel] Rationalization (Was: Questions regarding blocking ...)

On 08/04/2014 09:19 AM, Yaron Minsky wrote: Also, why does having more peers take more resources? The rough algorithm (IIRC) is: pick a random host from your list of peers; reconcile; wait a fixed period of time and try again. The set of hosts from which you pick a peer seems like it adds no

Re: [Sks-devel] Keydump

On 07/14/2014 03:00 AM, Henning Kopp wrote: I am a Phd student and want to do some research on gpg-keys. Perhaps you know about factorable (https://factorable.net/) where some researchers scanned the internet for ssl/tls-certificates. They tried some trivial factorization methods, like

Re: [Sks-devel] 1.1.5 is in wheezy-backports

On 06/10/2014 07:10 AM, Gabor Kiss wrote: It would be useful if postinst script checks free space before copying /var/lib/sks/DB/key to /var/backup/sks/. Now I have a stopped system with unconfigured sks package. Probably I have to delete the weekly keydump in order to get more disk. yes,

Re: [Sks-devel] Question: serving two different SSL certificates under Apache?

On 06/10/2014 10:41 AM, Stephan Seitz wrote: In the end, I ended up with TWO VirtualHost blocks in the Apache config after all. All works now, as long as you remember to add NameVirtualHost *:443! For reference, the following is my full Apache config for HTTPS on keyserver.zap.org.au:

Re: [Sks-devel] 1.1.5 is in wheezy-backports

On 06/05/2014 07:44 AM, Karl Schmitz wrote: IMHO, the account check is a bit exaggerated, isn't it? The administrator should be free to alter debian-sks's home. Well, the maintainer scripts and general defaults all assume that /var/lib/sks is where the data will be stored. If the packaging

[Sks-devel] 1.1.5 is in wheezy-backports

Hi folks-- I built SKS 1.1.5 against debian wheezy, tested it, and it is now in wheezy-backports. If you're running debian stable, and you want to move to sks 1.1.5, you should set up the wheezy-backports repository [0] and install sks from there. At the moment, only the amd64 platform is

Re: [Sks-devel] Heartbleed ans HKPS pool

On 05/27/2014 09:27 AM, Dmitry Yu Okunev (pks.mephi.ru) wrote: BTW, is it right that our server is not in the HKPS pool hkps.pool.sks-keyservers.net. Server: keyserver.ut.mephi.ru (85.143.112.59) $ host hkps.pool.sks-keyservers.net hkps.pool.sks-keyservers.net has address 162.243.102.241

Re: [Sks-devel] Dirmngr now supports hkps

On 05/07/2014 03:51 PM, Werner Koch wrote: On Wed, 7 May 2014 18:17, kristian.fiskerstr...@sumptuouscapital.com said: I strongly suggest using the original hostname provided as SNI when performing keyserver lookups, this is also consistent with current Okay. What about a dirmngr options

Re: [Sks-devel] Fwd: CVE request: SKS non-persistent XSS

On 05/02/2014 06:24 PM, Kristian Fiskerstrand wrote: Plerror is local logging and not passed to a web client In that case, why use html_quote s for the arguments to plerror when handling Bad_request ? Thanks for such a quick response, --dkg signature.asc Description: OpenPGP digital

Re: [Sks-devel] Configuring the reverse proxy to support large keys - HTTP error 413

On 04/28/2014 02:07 PM, Phil Pennock wrote: For now, if it's taken 15 years for someone keen on key signings to reach a 1MB limit, then I think that 8MB, covering 120 years of activity at such a rate, is likely to be enough for most normal mortal human beings. It's certainly enough to set as

Re: [Sks-devel] status page

On 04/18/2014 04:42 PM, Simon Lange wrote: bad ppl could pretend offering a public service using my machines they dont own nor they administre nor they run. my machines would support that passivly. think this is easy to understand. and also has some legal implications. just imagine feds want

Re: [Sks-devel] HKPS configuration?

On 02/11/2014 10:27 AM, Christian Reiß wrote: hkps is basically a 443 to hkp forward - I am using nginx for that. Just be SURE you do NOT use SNI or rely/ need a vhost/hostname as some client/most clients (gnupg) do not send this information. It is actually only feasible on a dedicated IP for

Re: [Sks-devel] Tuning

On 02/11/2014 10:48 AM, Kristian Fiskerstrand wrote: By default stats are updated once a day, for more than this you need to send a USR2-signal to sks. In particular, you need to send USR2 to sks db, not sks recon. And note that while sks db is calculating stats, it cannot serve HKP requests.

Re: [Sks-devel] Tuning

On 02/11/2014 01:58 PM, Benny Baumann wrote: Am 11.02.2014 16:59, schrieb Kristian Fiskerstrand: Unless you run it in a clustered setup where the different members calculate it on different times and the frontend passes the request on before timeout :p Its almost instantly for my maschine

Re: [Sks-devel] Debian vs SKS

On 12/16/2013 02:53 PM, Teun Nijssen wrote: https://lists.debian.org/debian-release/2013/12/msg00432.html Please don't characterize this ongoing discussion as Debian vs SKS. The Debian project and the SKS project are not in conflict. Regards, --dkg signature.asc Description: OpenPGP

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

On 12/03/2013 06:11 AM, Karl Schmitz wrote: maybe you should suggest adding the IPv4 compatibility DNS record (i.e., *sks-peer :::94.142.241.93*) to the administrator of sks-peer.spodhuis.org. To see if that'll work out, try adding an equivalent record to your /etc/hosts

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

On 12/03/2013 11:41 AM, Kim Minh Kaplan wrote: But this *is* the approach that SKS uses, except that it does not have to set IPV6_V6ONLY. Like I wrote in a previous answer, SKS requires the administrator to list all addresses, IPv4 and IPv6. As an alternative you can use the hostname. But I do

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

On 12/03/2013 12:34 PM, Phil Pennock wrote: IMO, SKS should either set v6only on the accepting sockets explicitly, or remove the defaults and treat :: and 0.0.0.0 as a configuration error, since the status quo uses inconsistent logic to defend its stance. I like these suggestions. Thanks for

Re: [Sks-devel] wiki man-page link; readthedocs.org ?

On 12/01/2013 09:49 PM, Phil Pennock wrote: If anyone knows of a similar documentation hosting project which might be a better match, please do let me know. This isn't exactly what you want, but http://manpages.debian.org/man8/sks should provide you with the latest man pages available in

Re: [Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

On 11/27/2013 04:30 PM, Phil Pennock wrote: On 2013-11-27 at 12:57 -0500, Daniel Kahn Gillmor wrote: i'm running sks 1.1.4 on Debian GNU/Linux, wheezy, amd64 (x86_64) platform. I see the following situation in the logs of the recon process (this is just an example, it seems to happen to all

[Sks-devel] IPv4 vs. IPv6? -- Reconciliation attempt from unauthorized host, but host is authorized

i'm running sks 1.1.4 on Debian GNU/Linux, wheezy, amd64 (x86_64) platform. I see the following situation in the logs of the recon process (this is just an example, it seems to happen to all my IPv4 peers): 2013-11-27 12:37:17 address for sks-peer.spodhuis.org:11370 changed from [] to

Re: [Sks-devel] pain of joining hkps -- reverse proxy config in apache issue with hkps.pool.sks-keyservers.net

On 11/08/2013 03:33 PM, Nat Howard wrote: Unfortunately, I made the mistake of asking Kristian if I was done now. And his answer was, Make sure to setup the vhost for hkps.pool.sks-keyservers.net and he was kind enough to give me the exact command that should work: curl --cacert

Re: [Sks-devel] Status flags are red

On 10/28/2013 08:22 PM, Jeremy T. Bouse wrote: I use StartCom for my SSL CA provider and they allow SANs to be added for SNI. I don't think that startcom is an appropriate CA for the current hkps.pool.sks-keyservers.net. In the current setup, anyone who has configured keyserver

[Sks-devel] sks recon without sks db

hi SKS folks-- I'm working on systemd service files for sks, for people who want to run sks under that initialization/supervision system. I was wondering if sks recon is able to do any useful work if sks db is not running. I'm not clear on the specific mechanics of the recon protocol -- do

Re: [Sks-devel] Quickie Script to Check your status in the pool

On 10/05/2013 05:30 PM, Todd Lyons wrote: Hey all, if you're like me, you are curious what pools you might be serving data for at any given point in time. The status page at http://www.sks-keyservers.net/status/ tells you what it thinks of your keyserver, but it doesn't tell you all of the

[Sks-devel] why does SKS have /dev/random open for writing?

hi SKS folks-- I was just looking at the behavior of sks 1.1.4, and i noticed that it seems to have /dev/random open for writing: 0 zimmermann:~# lsof /dev/random COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sks 742 debian-sks3w CHR1,8 0t0 1244 /dev/random sks

Re: [Sks-devel] why does SKS have /dev/random open for writing?

On 09/19/2013 01:39 PM, Kristian Fiskerstrand wrote: gentoo1 sks # lsof /dev/random COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME sks 11839 root3r CHR1,8 0t0 1157 /dev/random sks 31332 root3r CHR1,8 0t0 1157 /dev/random hm, so it's open for

[Sks-devel] SKS should not accept or propagate User IDs with no self-sigs [was: SKS should not accept or replay non-exportable certifications]

Hi John, all-- On 09/14/2013 09:46 PM, John Clizbe wrote: Careful here. Gossip is referring to recon and there is no other option in recon. Keys are just blobs of bits with a hash value. We can control what we accept, to try and make it conform to RFC 4880, et alia,... as much as possible,

Re: [Sks-devel] SKS should not accept or replay non-exportable certifications

On 09/14/2013 05:00 PM, Robert J. Hansen wrote: [dkg wrote]: I have told numerous people that the keyserver network will not propagate local signatures. This is true. No, unfortunately, it is not true in any way for SKS 1.1.4 (and probably earlier versions, though i have not tested). In

[Sks-devel] SKS should not accept or replay non-exportable certifications

SKS appears to be in violation of RFC4880 by freely importing and exporting non-exportable certifications. Background -- The OpenPGP specification includes a certification subpacket known as Exportable Certification. When present, and set to 0, it indicates that the certification is

Re: [Sks-devel] sks recon failed with Sys_error(Bad file descriptor) during reload

On Wed 2013-06-26 11:32:08 -0400, Daniel Kahn Gillmor wrote: I'm running sks 1.1.3 on a debian system, and it uses the logrotate package to ensure that the logs don't get out of control. this means that they rotate daily, and when they rotate, the system invokes: /etc/init.d/sks reload

Re: [Sks-devel] sks 1.1.4 fails to start

On 08/16/2013 10:03 AM, James Cloos wrote: It looks like this might be a debian error. sks-1.1.4 from debian experimental fails reliably when using sid, as of the latest upgrade to libdb5.1 (5.1.29-7) in sid. thanks for reporting this as http://bugs.debian.org/719876 -- it sounds to me like

[Sks-devel] sks 1.1.4 in debian experimental

On 07/31/2013 11:10 PM, Daniel Kahn Gillmor wrote: I've got a version of 1.1.4 that i'm considering uploading to experimental soon, but i haven't tested it yet, so i don't really want to foist it on the public. I've now tested sks 1.1.4, and it works for me. I've uploaded it to the debian

[Sks-devel] ks-status-json.php should include HKPS info [was: Re: ks-status-json.php should emit Content-Type: application/json]

On 08/01/2013 11:55 PM, Daniel Kahn Gillmor wrote: I was just checking on keyserver status here: https://sks-keyservers.net/status/ks-status-json.php?server=zimmermann.mayfirst.org hm, and while i'm at it, i note that the json version doesn't mention HKPS, which is mentioned on the non

Re: [Sks-devel] Raising Sys.Break -- PTree may be corrupted: Failure(add_to_node: attempt to reinsert element into prefix tree)

On 07/31/2013 10:57 PM, Christoph Anton Mitterer wrote: Well the problem for me is that it's not yet in Debian and I'm not very keen on keeping keeping it up to date manually. Does anyone else here know what's the status there? Christoph Martin seems to be a bit inactive :( I've got a

Re: [Sks-devel] sks 1.1.4 in debian/ubuntu

On 06/26/2013 02:36 AM, H.-Dirk Schmitt wrote: just a little question - is somebody working on the debian integration of 1.1.4 #690135 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=690135This would help to fix also #1096116 https://bugs.launchpad.net/ubuntu/+source/sks/+bug/1096116 on

[Sks-devel] 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

Re: [Sks-devel] Keyserver operators with reverse proxies: read this please

On 03/01/2013 02:03 PM, Phil Pennock wrote: I have updated https://bitbucket.org/skskeyserver/sks-keyserver/wiki/Peering already. Thank you for sorting this out, Phil, and for taking it all the way to concrete suggestions. This is really helpful and useful. nginx - [...]

Re: [Sks-devel] Peering wiki text updated

On 02/27/2013 12:36 PM, Kristian Fiskerstrand wrote: Are the ServerAliases strictly necessary for a port binding to 11371? Presumably you're not using canonical names to determine the service. If the aliases really are necessary, keep in mind that some pools are using a CNAME to

Re: [Sks-devel] sks responding extremely slowly if at all

On 02/25/2013 03:21 PM, David Benfell wrote: If I'm reading this right, it's still running, but these timeouts are ridiculous: graton% gpg --recv-key 2512E3C7 gpg: requesting key 2512E3C7 from hkp server disunitedstates.com gpg: keyserver timed out gpg: keyserver receive failed: keyserver

Re: [Sks-devel] Idea: dump should create keycount.txt

On 11/07/2012 12:06 PM, Stephan Seitz wrote: that was exactly the same what thought of. I'ld just go a little step further to xml, so machines could parse it more easily. for simple data like we're talking about, Kim's proposed syntax seems at least as easy for a machine to parse as XML, and

Re: [Sks-devel] expiration date in machine readable results

On 10/18/2012 07:39 PM, Daniel Kahn Gillmor wrote: get_times in ParsePGP.ml checks the subpacket type against ssp_exptime_id, which is set to 3 (which is correct, afaict [3]). ah, looking a bit closer, i think i understand the situation here. when gpg sets the key expiration time, it does so

Re: [Sks-devel] sks-keyservers.net New HKPS subpool added

On 10/05/2012 06:23 PM, Phil Pennock wrote: Speaking for myself, I only use TLSv1+ and my nginx is built with SNI support, so if you want to figure out a policy for handing out certs, I can add a new cert for SNI hostnames in *.pool.sks-keyservers.net. alternately (or in addition?), we could

Re: [Sks-devel] Request for SKS gossip peers

On 09/08/2012 08:23 AM, Andreas Thulin wrote: Would you say an e-mail to the sks devel sendlist explaining my predicament could be one way of getting further in the process? yes, it would. you're already sending mail to sks-devel, you know :) please indicate specifically what you tried, what

Re: [Sks-devel] sks-keyservers.net: Now in the monkeysphere

On 08/10/2012 01:34 PM, Gabor Kiss wrote: [kristian fiskerstrand wrote:] As an FYI; I've now added HTTPS/TLS support to https://sks-keyservers.net . It is part of the monkeysphere[0], i.e. using a self-signed certificate that can be verified through the Web of Trust of OpenPGP. The KeyID of

Re: [Sks-devel] dealing with misplaced signatures

On 08/01/2012 12:44 AM, David Shaw wrote: hiding the packets is potentially harmful. [...] hiding the packets from GPG prevents this repair from happening. After all, if GPG doesn't get the packets, it can't move them to the right place. This means the signatures are effectively lost,

Re: [Sks-devel] dealing with misplaced signatures

On 08/01/2012 01:12 PM, David Shaw wrote: My point is that if you expect GPG to be able to fix a broken key, you need to pass back all the data, or GPG has nothing to work from. well, you could expect the GPG of the original uploader to fix the broken key before uploading it. Then the

Re: [Sks-devel] dealing with misplaced signatures

On 07/31/2012 06:04 PM, Kristian Fiskerstrand wrote: Currently we have a patch[0] ready that allows for these signatures to be cleaned in the getting (and vindex) of the key, A patch with the stated functionality would be a Good Thing. However, before creating a Pull Request into the SKS

[Sks-devel] sks should not allow id cert packets after a subkey

Clint Adams just reported: http://bugs.debian.org/683328 This key is buggy: http://keys.mayfirst.org/pks/lookup?op=getsearch=0xED34CEABE27BAABC Note the 0x10 and 0x13 signatures on the 4096-bit subkey; these should not be there. Please check the signature types and only

Re: [Sks-devel] Being dropped from the pool

On 07/27/2012 01:08 PM, Kiss Gabor (Bitman) wrote: I'm just came back from the holliday. welcome back! Surprisingly I found the keys.niif.hu is not in the pool. More precisely no servers running SKS 1.1.1 is included. I quickly scanned the recent mails of sks-devel but I found no

Re: [Sks-devel] sks nginx config

On 07/26/2012 10:40 AM, Kristian Fiskerstrand wrote: add_header Via 1.1 keys.kfwebs.net; I've added a similar directive to the nginx configuration on zimmermann.mayfirst.org. --dkg signature.asc Description: OpenPGP digital signature ___

[Sks-devel] recon outage on zimmermann.mayfirst.org

hey folks-- it looks like the sks recon process on zimmermann.mayfirst.org (a.k.a. keys.mayfirst.org) stopped about 10 days ago: 2012-07-16 05:28:34 Raising Sys.Break -- PTree may be corrupted: Bdb.DBError(unable to allocate memory for mutex; resize mutex region) yuck. After stopping sks, I

Re: [Sks-devel] recon outage on zimmermann.mayfirst.org

On 07/27/2012 12:03 AM, Jeffrey Johnson wrote: Running dbXY_stat -CA (for all status: -Cl is usually all that is needed) will display hung deadlocks. hm, what i'm seeing is that db4.8_stat -CA hangs itself, within a similar futex call: 0 zimmermann:~# strace -p $(pidof db4.8_stat) Process

Re: [Sks-devel] recon outage on zimmermann.mayfirst.org

Hi John-- thanks for the followup! On 07/27/2012 12:59 AM, John Clizbe wrote: echo KDB -- cd KDB sudo db53_recover -ev sudo db53_checkpoint -1 sudo db53_archive -dv sudo db53_recover -ev cd .. echo PTree -- cd PTree sudo db53_recover -ev sudo db53_checkpoint -1 sudo db53_archive

Re: [Sks-devel] Moving the main repo

On 07/03/2012 07:41 PM, Yaron Minsky wrote: Just a quick note. We've moved the main repo from it's old location at https://bitbucket.org/yminsky/sks-keyserver to this one https://bitbucket.org/skskeyserver/sks-keyserver Thanks for the heads-up, Yaron. I (think i)'ve updated the

  1   2   >