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

[Kristian Fiskerstrand]

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

On 04/09/2014 02:36 AM, Martin Papik wrote:
> Dear Kristian
> 
> Thank you for your response.
> 
>>> 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]
> 
> So all the keys will be in the database on a 1.1.3 server, but 
> searching for ECC keys will fail with an error, and ECC signatures 
> will be omitted due to the filter which can be disabled with 
> clean=off. Did I understand you correctly? In which case, a 1.1.4

... yup

> server that is only peering with a single 1.1.3 server which peers 
> with the networ will get all the keys and return correct results.
> Is that true? Will a dump on a 1.1.3 contain the ECC key material?

... yup

> 
>>> 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.
> 
> Which requirement is this? For the ECC-safe pool? Because
> otherwise this seems to contradict the next paragraph.

the subset pool was linked as reference [0]

> 
>> 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].
> 
>>>> 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.
> 
> Do you have a time frame in mind?

No specific timeframe, I have an outstanding pull request on its way
into the main tree, after that I'm ready to go after some release
preparations, but it depends on whether the rest of the team has
anything outstanding.

> 
> Are the planned improvements documented somewhere? Are they in the 
> repository in the TODO file?

they are in the CHANGELOG [a]. The todo file isn't really used, we use
the issue tracker instead.

> 
> Is the repository always the latest version?

I don't understand this question.

> 
> Is the repository always safe to run? I mean, can the head always
> be safely deployed to be part of the public network?

No, it is a development branch. However, it is mostly iterative and as
such save, but "always" is a very strong requirement.

> 
> PS, sorry if my questions are tedious, but I'm new to sks so
> there's a lot that's not clear to me and I would like to make sure
> I don't misunderstand something. I hope it's okay.

Sure..


References:
[a]
https://bitbucket.org/skskeyserver/sks-keyserver/src/tip/CHANGELOG?at=default

- -- 
- ----------------------------
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
- ----------------------------
Docendo discimus
We learn by teaching
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJTRPajAAoJEPw7F94F4TagyxUP/1N7UcUr6KIBkF/rxBF9ebN0
OmjE4HpA5J/s7ymrm74KuNYZUnVR7WLzCfe94mAEUDtWKfD/gxRBdD59ip4xLe/G
HyL9xhJ/fDW9uC6OAMPB0rxm1vpptipVKf7FtHaJsiAVIb9PLHjZHATNNyTmQpDx
aJ86GXsJaWaLQbF0o8QC92xjHF1aUVPspmS3jTrXUTqLMPxXmFtuLttuL4EzA+bb
VycOUm0RB7F1e9E5ahQ75wTgS0HbmmkDD0+WW8P9LROwfUeF/XCJDXTCCYV0nsKc
Litg9cTKuKLmAD1vwO526MXRxU2cmycki26PRAwIW+PT18xE+2LXBPrW/5zRrK4F
lQOJTxd0GGN8tIeA41OIyqgQM2QGNiLozdAtrcJx6Xr6+0p1tcjbEml4xfCX2DHr
ZqFjxTLuNFCK+muhwlc1MswcY7cR3+xOwuVkvOP4gHJRYM3teqGQpBJRGUVgnmRr
yAANAZhY70hAoVgD1WAv2AK+Yj2IGRxj2ctzfIULp+E3Y/DzYqeYVaPs+iqNsIPm
UpOARkoMvXBt5KWIHW23z0oOv/nMZ2nOAwMx/RabpzEy6FOKpHk/UgsfZSbP9TaC
n1ZGWg5svLBYgFw7+Cb4HMYWM7oYvxwUGY3+OsSbODpGKLk5XouSfBy3sSK+Kbv1
6VRTVWS7QCldvOy1Lg76
=Qq8Y
-----END PGP SIGNATURE-----