On 02/13/2009 10:21 PM, Phil Pennock wrote:
Normally, sks consumes a negligible amount of the resources on my
server; some GB of disk, some MB RAM (~45 right now, after restart), not
enough network that I've bothered to isolate figures for it.
I just found that my box was thrashing badly
On 02/14/2009 05:24 PM, Phil Pennock wrote:
So, the options behind it, if the correlation is more than coincidence,
seem to be:
1 bad SKS update
2 bad query hitting pool.sks-keyservers.net
3 someone hitting the servers individually deliberately
4 someone doing full sync of a keyserver
On 02/15/2009 06:33 PM, Ryan wrote:
Yea, I am pretty sure I am the one going haywire.. sorry guys, trying to
figure out exactly what the hell is wrong...
Thanks for the quick and excellent detective work, Phil and Ryan! Since
i restarted sks on zimmermann.mayfirst.org, and Ryan took his system
On 03/07/2009 03:03 PM, Joseph Oreste Bruni wrote:
On Mar 7, 2009, at 8:11 AM, Gab wrote:
I wish to in https ssl the sks web interface .
What are the directives for cert.pem and key.pem and to enable ssl ?
I don't believe that the built-in web server supports SSL. However, you
could
On 03/07/2009 09:37 PM, David Shaw wrote:
On Mar 7, 2009, at 7:30 PM, Daniel Kahn Gillmor wrote:
We also are listening on port 11372 because this seems to be the choice
of gnupg maintainers for hkp-over-tls (hkps?), according to this recent
(as yet unreleased) patch to gpg:
http
On 03/10/2009 11:52 PM, Gab wrote:
Hi i was looking for the command after sks db id buid to get sks running.
I'm not sure what you're asking -- can you try rephrasing it? Your
subject line commands to optimize and debug sks after install doesn't
seem to agree with to get sks running.
If you
On 03/15/2009 11:23 AM, Gab wrote:
Daniel Kahn Gillmor wrote:
On 03/07/2009 03:03 PM, Joseph Oreste Bruni wrote:
On Mar 7, 2009, at 8:11 AM, Gab wrote:
I wish to in https ssl the sks web interface .
What are the directives for cert.pem and key.pem and to enable ssl ?
I don't believe
On 03/22/2009 09:02 AM, Kim Minh Kaplan wrote:
Daniel Kahn Gillmor:
gpg generates an HTTP request like this:
http://$foo:11371/pks/lookup?op=indexoptions=mrsearch=0xD21739E9exact=on
[...]
What is the right way to handle this?
The simplest solution would be to remove the exact
On 03/22/2009 06:41 PM, David Shaw wrote:
The 'exact=on' problem is specific to 1.0.10. It worked properly in 1.0.9.
See: http://www.mail-archive.com/sks-devel@nongnu.org/msg00287.html
Ah, thanks for the pointer, David.
Given that this causes problems for users of gnupg, has any thought
On 03/22/2009 10:29 PM, Yaron Minsky wrote:
I'm really confused. People have piped in in both directions on this one,
so does someone have the definitive story? Is 1.0.10 the one that behaves
correctly, or 1.0.9?
So far i haven't heard anyone claim that 1.0.10 works correctly. 1.1.0
works
On 03/23/2009 04:02 PM, David Shaw wrote:
On Sun, Mar 22, 2009 at 07:41:50PM -0400, Daniel Kahn Gillmor wrote:
has any thought been
given to requiring members of the keyserver pools to not run that
version of SKS? keys.gnupg.net itself contains several keyservers
running 1.0.10, which
On 03/23/2009 07:05 PM, John Clizbe wrote:
David Shaw wrote:
None that I know of. Eventually, such a thing will be necessary, but
it would have to be done via whoever controls the particular keyserver
round-robin.
Or convince the keyserver operators running 1.0.10 to upgrade to 1.1.0
or
On 04/03/2009 08:01 AM, Werner Koch wrote:
On Mon, 23 Mar 2009 21:17, d...@fifthhorseman.net said:
keys.gnupg.net is pretty new and I configure it manually. I poll the
keyservers every hour or so to see whether they are still responding and
send a mail if they don't response. Everything else
On 04/10/2009 11:15 AM, Leonhard Kugler wrote:
Debian Lenny with Ocaml, Barkley, SKS from the sources (Virtual Machine)
This one ought to work smoothly -- i'd focus on it, if i were you.
Debian Etch with Ocaml, Barkley (4.2) from the sources and sks-1.0.10
Why did you choose to go with etch
On 05/04/2009 07:23 AM, Yaron Minsky wrote:
If we have lots of SKS
keyservers that don't have mailsync's, I'm afraid the PKS network will get
left behind...
/etc/sks/mailsync in the sks debian package says:
# IMPORTANT: don't add someone to your mailsync file without getting
# their
i thought sks folks might be happy to see the following note that was
posted today to gnupg-devel. an inspection of the HKP headers (and the
pgp.mit.edu web interface) confirms it.
A big thank you to the keyserver folks at MIT for making this transition!
--dkg
---BeginMessage---
It
Hey folks--
I appear to be getting no A records for pool.sks-keyservers.net. this
seems like a Bad Thing.
is anyone else seeing this? it's forcing my nameservice resolution to
fall back to IPv6, which is link-local only for a number of my machines
which don't have connections to any of the
On 07/02/2009 02:16 PM, Joseph Oreste Bruni wrote:
Same here. I'm getting all records.
fwiw, i'm getting valid A records (not ) from
subset.pool.sks-keyservers.net, so at least some pieces of the
infrastructure are working as expected.
Kristian, can you clarify what's going on with the
On 07/02/2009 07:29 PM, Jonathan Oxer wrote:
On Thu, 2009-07-02 at 18:22 -0400, David Shaw wrote:
On Jul 2, 2009, at 6:04 PM, Jonathon Weiss wrote:
I think we've reached the point that if someone is still running PKS,
they should either convert to something without the subkey problems,
or
On 07/02/2009 10:07 PM, John Clizbe wrote:
Daniel Kahn Gillmor wrote:
http://pks.sourceforge.net/pgp-keyserver-folk.html
The last message on that list was 02-Jul-2007. It's been silent since.
Yeah, my message to that list bounced with:
pks-keyserver-f...@alt.org:
64.71.163.201 does
On 07/02/2009 10:53 PM, Daniel Kahn Gillmor wrote:
pks-keyserver-f...@alt.org:
64.71.163.201 does not like recipient.
Remote host said: 550 Unrouteable address
Giving up on 64.71.163.201.
d'oh! i see now that i munged up the pks list address. But when i
tried to send another message to what
On 07/06/2009 06:56 PM, David Shaw wrote:
DNS-SD can work with the zeroconf and mDNS stuff, but it is its own
beast. What I am doing should lay some groundwork if someone wants to
take things a step further (find your keyserver automatically on a LAN,
for example), but that's not what I'm
hi kristian--
it looks to me like pool.sks-keyservers.net is returning no records again:
0 d...@pip:/tmp/cdtemp.vYCai8$ dig pool.sks-keyservers.net @ns1.kfwebs.net
; DiG 9.5.1-P2 pool.sks-keyservers.net @ns1.kfwebs.net
;; global options: printcmd
;; Got answer:
;; -HEADER- opcode: QUERY,
On 11/29/2009 07:03 PM, MailFighter.net Admin wrote:
r...@mx4:/var/lib/sks# sks build -n 13 -cache 100 /var/sks/dump/*.pgp
unknown timeout type argument to DB_ENV-rep_get_timeout
Segmentation fault
It SIGSEGV's immediately. It's not a RAM problem.
I'll compile sks manually and ignore
On 11/30/2009 09:05 AM, MailFighter.net Admin wrote:
Also, my main interest is to have some sort of XML or machine parseable
output over the http
interface, so I can implement a set of features into Enigform.
The output should already be machine-parseable (though it's not XML).
Have you read
On 11/30/2009 12:22 PM, MailFighter.net Admin wrote:
My interest is in being able to get what keyids have signed a certain key, in
a machine parsable format.
Keyservers can't actually tell you that reliably. As far as i know, SKS
does no cryptographic validation on the signatures it
On 02/01/2010 02:22 PM, Phil Pennock wrote:
On 2010-02-01 at 11:47 +0100, Sebastian Wiesinger wrote:
my sks recon server is using waaay to much memory:
lita:~# ps auxww | fgrep sks
126 4317 0.0 1.1 70584 47372 ?S 2009 35:20
/usr/sbin/sks db
126 4320 0.0 40.4
Hi Jonathan--
Thanks for the quick response!
On 04/01/2010 12:30 AM, Jonathan Oxer wrote:
Sorry I can't answer your other questions, but I just had a look in
db.log and found ...
* How often
do you see queries?
...about 10k queries / day to keys.keysigning.org, which is in that
pool.
Hi Ryan--
On 04/01/2010 12:45 AM, Ryan wrote:
Couple thoughts, first of all if you have several
machines doing regular queries you might look into running
a local keyserver for your servers to sync off of.. if thats
not a possibility you might locate your closest server and
point it at them.
On 04/28/2010 06:29 PM, Jesus Cea wrote:
This is not good. An undocumented *key* feature, written in a obscure
programming language :).
I know it is not very appropiate to post this in this mailing list but...
I was wondering if there is any kind of demand of an alternative OpenPGP
From where i sit, 2 out of 10 of the servers returned by
pool.sks-keyservers.net are not responding to ICMP echo requests (pings):
193.174.13.74 (pgpkeys.pca.dfn.de)
94.46.216.2(sks.5coluna.com)
Given that the machines do respond to http requests, i wonder why they
don't respond to ICMP
On 03/18/2011 12:52 PM, Sebastian Urbach wrote:
Got a mail from Kristian a few seconds ago. He sais something
about hardware trouble.
perhaps this concept of the pool needs some or all of the following to
avoid future SPOFs:
0) hardware redundancy for the authoritative nameservers for
On 03/18/2011 02:38 PM, Jonathan Wiltshire wrote:
On Fri, Mar 18, 2011 at 01:45:52PM -0400, Daniel Kahn Gillmor wrote:
Kristian, i would happily offer zimmermann.mayfirst.org as a redundant
authoritative DNS server -- we'd just need to coordinate how the pool
gets published.
I suggest DNS
Hi SKS folks--
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:
https://bugzilla.gnome.org/show_bug.cgi?id=645995
If anyone here uses seahorse regularly, and could test their fix and
Hi folks--
I just upgraded zimmermann.mayfirst.org (a.k.a. keys.mayfirst.org) to
run SKS 1.1.1 (using stock debian squeeze packages).
The upgrade went pretty smoothly; i think there was about 5 minutes of
downtime total.
My notes on the upgrade from debian lenny to debian squeeze for this
On 04/04/2011 06:40 AM, Jean-Jacques Brucker wrote:
1- As ECC crypto is soon available in gnupg, I am asking if sks key servers
won't have problems managing them.
(That is a great feature I am waiting for to use gpg with signing chains)
But the ECC curves are smaller than RSA or DSA
On 04/05/2011 09:33 AM, Jean-Jacques Brucker wrote:
I didn't know that fingerprint was calculated with a timestamp. Do you have
any idea of the reason(s) to do that ?
You should read RFC 4880 (or just skim it and read the parts that most
interest you):
https://tools.ietf.org/html/rfc4880
On 04/05/2011 11:35 AM, Jeff Johnson wrote:
The current V4 scheme (from memory, see RFC 4880 for specifics) to assign
a fingerprint to a pubkey (including all of RSA/DSA/ECC) involves running
a SHA1 digest across conventionally defined plaintext that involves the
alogrithm
parameters and
On 04/12/2011 01:58 PM, John Clizbe wrote:
My first big hit came from pgp.surfnet.nl ~0930 CDT (US/Central - UTC-5:00)
Here's zimmermann.mayfirst.org's log of recent large (99) hashdumps via
recon (timestamps are America/New_York):
0 zimmermann:~# cd /var/log/sks
0 zimmermann:/var/log/sks#
On 04/19/2011 02:04 PM, Kristian Fiskerstrand wrote:
All email addresses are mangled in my client here, and you don't seem to
have signed the message so I can't find it in a UID, but if you send me
an email off-list I can send them to you.
Is there a possibility of releasing them as free
hey sks people--
You might (like i did) have one of the following busted links in your
SKS server index.html:
http://www.nongnu.org/sks/ appears to redirect to
http://minskyprimus.net/sks/
but the minskyprimus.net domain name appears to have expired last week.
The content that used to live
On 05/12/2011 10:53 PM, Yaron Minsky wrote:
My apologies. I'm in the process of transferring the domain, and will
reinstate it.
It's worth noting that the best place for keeping info about sks is I think
the google code site:
http://code.google.com/p/sks-keyserver
Thanks for the
On 06/01/2011 01:14 PM, Xian Stannard wrote:
I can see that it is bad to loose keys that are in use, but why must
every key from day zero be kept? The deletion need not be probibitive of
the key being uploaded again: that could trigger it to be re-propagated.
I have (locally) a copy of key X
On 06/01/2011 06:06 PM, Scott Grayban wrote:
You can search the keyserver using just the email address and they would
still get the new pub key
The point is that they would not know that the old one had been revoked
or expired. This is a significantly bad outcome.
--dkg
On 06/16/2011 11:15 AM, Javier Henderson wrote:
Who is running a keyserver at 2a01:4f8:100:2ffe::2?
this is tomakin.h-ix.net, according to
dig -x 2a01:4f8:100:2ffe::2
and the forward lookup provides the same mapping:
dig tomakin.h-ix.net
Whois provides some information about who to
hi folks (and kristian in particular)--
the pool is reporting that zimmermann.mayfirst.org is not responding:
http://sks-keyservers.net/status/info/zimmermann.mayfirst.org
but it appears to be responding to me:
http://zimmermann.mayfirst.org:11371/pks/lookup?op=stats
any idea why there's
Hey SKS folks--
It appears that SKS 1.1.1's hkp interface is vulnerable to an ugly DoS
attack by a client holding open a network connection without completing
an HTTP request.
Demonstration
-
This is pretty easy to demonstrate using two terminal windows: use
netcat in one to connect
On 03/18/2012 10:36 AM, MailFighter.net Admin wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 03/13/2012 06:08 PM, Daniel Kahn Gillmor wrote:
It appears that SKS 1.1.1's hkp interface is vulnerable to an ugly DoS attack
by a client
holding open a network connection without
Hi John--
Thanks for looking into this.
On 03/18/2012 09:46 PM, John Clizbe wrote:
The default setting for wserver_timeout is 180 seconds.
Does setting it to a lower value in sksconf help?
I just tested with 10 instead of 180.
if i revert my nginx changes and allow sks back to listening on
On 03/19/2012 04:11 PM, 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.
Wow, very speedy -- thanks, Kristian! Works for me.
I think
On 03/20/2012 12:22 AM, Pacal Mayan wrote:
would implementing an accept filter help? i.e., accf_data or accf_http
on the socket?
I'm assuming you're talking about [0], which i think is FreeBSD only,
right? i'd never seen this sockopt before, thanks for pointing it out!
I haven't tested it
On 03/21/2012 08:08 AM, Phil Pennock wrote:
For nginx, if you listen on a port and only have one vhost, with no
default_server, will all requests for that hostname go to this server
spec?
I believe they will, yes. keys.mayfirst.org is also known as
zimmermann.mayfirst.org (and as
On 03/25/2012 05:53 PM, Kristian Fiskerstrand wrote:
Did a few more changes[0] to speed up the IP lookup process, and
included adding IPv6 for some subset pools (including the HA one)
Hm, just looking for the regular IPv4 A records for the HA pool from
different authoritative nameservers
On 04/20/2012 01:17 PM, Robert J. Hansen wrote:
If we're in need of 1.1.3 packages for Debian and Debian-derived
distros, I might be able to help. My OCaml is no better than functional
(pardon the pun) and my knowledge of .debs is far from comprehensive,
but I have free time to devote to
On 04/21/2012 06:56 AM, Andy Ruddock wrote:
DB versions in Debian :
stable has 4.6, 4.7 4.8
testing has 4.8, 5.1 5.3
unstable has 4.6, 4.7, 4.8, 5.1 5.3
Thanks for the summary! It's worth noting that the db maintainer in
debian would like to move exclusively to 5.3 before wheezy is
On 04/21/2012 09:57 PM, Robert J. Hansen wrote:
I've never packaged for the Debian trees: I've only ever made .debs for
my own local installation. Should I set up a VM with Debian Unstable
and build against that?
yes, building it against a debian unstable instance is a good idea.
On 04/28/2012 09:26 AM, Jens Leinenbach wrote:
As already discussed on this list, there is this old SKS bug using POST
requests without sending the http version, so ngnix denies these POST
request.
And I didn't find any workaround, so that ngnix can fix these requests.
It looks like you're
On 06/02/2012 06:45 AM, Phil Pennock wrote:
Someone needs to repoint http://www.nongnu.org/sks/ before the GC site
goes.
I've done this now, as well as updating the Homepage link seen at:
https://savannah.nongnu.org/projects/sks/
(since i can never remember how to do this in savannah, it's
On 06/25/2012 12:44 AM, Kristian Fiskerstrand wrote:
Please let me know if we should push the timeline some for the 1.1.2 minimum
to get more time for testing, as originally stated my primary goal is getting
to 1.1.3, so this shouldn't necessarily affect too much, we can still keep
that at
On 06/25/2012 02:16 AM, John Clizbe wrote:
After Christoph's last email re mutex_set_max I checked my own databases, both
of which were set to 64K. PTree was almost equally split between in-use and
free. KDB was very close to running out with only about 3K left of the 64K.
Would you mind
On 06/25/2012 04:43 AM, John Clizbe wrote:
Christoph Egger wrote:
The 1.1.1 package in stable is at 4.7. The 1.1.3 in unstable uses 5.1
and the backported sks 1.1.3 in stable-backports will be using 4.8 just
to add to the confusion ;-)
while (true) do
head-desk
done
*shakes head
On 06/25/2012 12:40 PM, Kristian Fiskerstrand wrote:
Again, thanks for helping out with the backport.
you're welcome :)
Ref the upgrade / backup bug, it might be better to upgrade the BDB
store using the steps in
https://bitbucket.org/yminsky/sks-keyserver/src/3d12f5a0d7cf/UPGRADING .
This
On 06/25/2012 12:43 PM, Jeffrey Johnson wrote:
On Jun 25, 2012, at 12:36 PM, Daniel Kahn Gillmor d...@fifthhorseman.net
wrote:
I'm open to other suggestions. I believe that the current upgrade path
(while hilarious in a sad sort of way) will actually work for most people.
Bundling SKS+BDB
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
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
___
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
-
[...]
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
1 - 100 of 163 matches
Mail list logo
