sks-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Sks-devel] SKS peering request [sks-server.randala.com]


From: Kristian Fiskerstrand
Subject: Re: [Sks-devel] SKS peering request [sks-server.randala.com]
Date: Mon, 07 Apr 2014 12:38:56 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

[Please do not top-post, it makes it difficult to follow the thread]

On 04/07/2014 05:12 AM, Martin Papik wrote:
> 
> Dear Phil
> 
> First of all thank you for your exhaustive response, it's much 
> appreciated.
> 
> I'm running it on real HW, so the Ptree issues are not a problem, 
> although I am curious to know why and how such corruption happens
> on a VM. Is it because of something specific to SKS or DBD? How was
> it fixed in 1.1.4?

It relates to the timing information in the kernel clocksource not
being accurate enough in some VM environments, so one of the
workarounds is to use the tsc clocksource.

> 
> Second, with 1.1.3, are ECC signatures lost? Meaning if someone 
> queries my server running 1.1.3 for a key containing an ECC
> signature, will only the one signature be missing or will there be
> problems syncing any further signatures?

For signatures the ECC signature will be gone by default, or an error
will be shown for a primary ECC key. The keys will synchronize and the
full key can be gotten from a 1.1.3 server using &clean=off option
that disable the presentation filter. You'll find some details on
number of ECC (primary) keys at [2]

> I.e. will the whole key be lost, the ECC signatures only, or any
> signature after the first ECC signature is added? Another question
> that occurs to me is, how many ECC signatures are actually in the
> wild? Are many users affected? If so, I wonder if the logic that
> selects my server for inclusion in the pool is doing the right
> thing. Mine isn't the only 1.1.3 server included. So I wonder.

ECC safe pool is the subset pool c.f. [0]. The 1.1.3 requirement is
set mainly due to subkey safe searching. This will be bumped to 1.1.5
once released.

> 
> I can't do much about OS packaging, it already took extra effort
> to get 1.1.3 on the current stable version (not much, but extra),
> maybe somebody here could undertake the effort needed to backport
> the latest SKS for the stable branch of ubuntu. I've never done
> anything with ocaml so I don't feel qualified to roll out a
> package. Not even for myself to be honest. Or rather, I'm not in
> the best mental shape to be responsible for such a thing.
> 
> So the question that sticks out is this, am I degrading the network
> by being included in the pool with a 1.1.3 server? If so, what
> next?

1.1.3 should be reasonably safe (in the meaning I don't have any
immediate plans to discard it form the pool), however do note that
1.1.4 was released in October 2012[1].

> 

> Martin
> 


...

> 
>> I believe that Kristian is currently trying to coordinate
>> getting some final changes in before a 1.1.5 release which will
>> have enough cleanups and improvements in ECC and web security
>> areas that it should be considered a "really really should
>> upgrade" release.

It would have its set of improvements, indeed. And you're correct in
that I'm in favor of a new release soon, although I must state the
disclaimer that we haven't decided on this in the team yet.


References:
[0] https://sks-keyservers.net/overview-of-pools.php#pool_subset
[1] http://lists.nongnu.org/archive/html/sks-devel/2012-10/msg00010.html
[2] http://blog.sumptuouscapital.com/2014/01/openpgp-key-statistics/
- -- 
- ----------------------------
Kristian Fiskerstrand
Blog: http://blog.sumptuouscapital.com
Twitter: @krifisk
- ----------------------------
Public PGP key 0xE3EDFAE3 at hkp://pool.sks-keyservers.net
fpr:94CB AFDD 3034 5109 5618 35AA 0B7F 8B60 E3ED FAE3
- ----------------------------
Qui audet vincit
Who dares wins
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTQoA8AAoJEPw7F94F4Tag9wUP/1F++7EJu33NsjCaj+0KSo4/
DFiiD1PXifp35KyCBsdV4fLxAgeen7bdMq08qbaTp8CAiK4MK4O8CNOj359s54sN
JI/hGIdMrcoTJp1RfCEee+9tdSiq0AIfm8HhZ2wdKcBF5gg1jumAV/wxX00V9rw3
KB+P+r83m6nS+BKMzAljKjX/WbFTr+7o13LKv1NSJO9Dfkpd2eLszCDAfVWixKw9
Tj0YmCuiKoQLIUDeWr8qQob4GSfLlLaBuuqBqn0SJNpQivo7pvF10mk5Z1bNkRhh
qAWBxMKVLNhnB7ke1o2j5C5mkMg8LdgHUnWw4bIj3O/YRSXf+Q+A6QdhijOryh/J
IKwri/xp2vdIE6NnPs7NJjg9O8zup0kRqE+f8glI6txmXFBzoNS5NjWPStewl13N
9SRixLiOTFkZoQ73QvBKu2IHcX0Z8yk9vGP0uR7JGbPKNC5vnBA7ZvImc+HJ2rqw
ouwPvpmv8wFnps6CClDKlYS6VGi3gCQIvdnDpdm6B5lrshHDpRLlQmpKIWRoa0OQ
0tNnBmPb8ziQJDyGCmbOzh6bQ+54uGAjhi/Zvc25Vj0ORuDzIOKgscbkHGDb0lY7
IpOWEkCw0VCzUp4q95JFSR0cLF7qWJ3EvPR/9ODztuW3SM3OD2k0GeeF1IWVgQc2
VvfNFrGYUH699OT2uHrA
=E96u
-----END PGP SIGNATURE-----



reply via email to

[Prev in Thread] Current Thread [Next in Thread]