sks-devel
[Top][All Lists]
Advanced

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

Re: [Sks-devel] One Way replication (for test environments)


From: Andrew Gallagher
Subject: Re: [Sks-devel] One Way replication (for test environments)
Date: Mon, 18 Jun 2018 11:27:07 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0

On 18/06/18 11:11, Hendrik Visage wrote:
>> On 17 Jun 2018, at 14:59 , Andrew Gallagher <address@hidden
>> <mailto:address@hidden>> wrote:
>>
>> You can’t do it using recon, because any additions to the test server
>> will cause the key delta to diverge and recon will eventually fail.
> 
> Do you mean that the recon *needs* a similar from the destination?

Unless recon is enabled in both directions, the key delta will
inevitably grow to the point that recon will fail. It might take a long
time, but it will happen eventually - and as the delta grows the load on
the recon partner will increase.

> I don’t really care about it failing,

Recon failure is very messy and affects both sides of the recon.

> the idea might be to inject problem keys into
> the tet environment, and the test environment’s problem keys not to
> “infest” the current public SKS keyservers.

The only way to reliably prevent leakage of test data into the wild is
to block all communication between test systems and production ones. A
recon that works in one direction and not the other is fine until the
day that you redeploy the server and forget to add the configuration
that blocks comms in the wrong direction!

If you rely on a highly specific configuration to prevent utter
disaster, then utter disaster is inevitable the first time something
goes wrong. And something *will* go wrong... ;-)

> The type of troubles we saw, I read as something that was caused as the
> updates was being recon’s between servers, after the problem keys was
> already injected, thus the idea would be multiple servers to test
> against, having some ingres feeeds from the public servers, but no
> egress to the public side. Might be good for others to test there “test
> certs/keys” against before actual publication??

The beauty of docker images is that you can spin up as many copies as
you like and get them to recon with each other.

For a test setup, I would strongly recommend using VMs or docker images
that have no connectivity whatsoever with the internet. Build them from
dump images and run them in an isolated environment. If you want random
people to be able to use them for testing, then enable port 80 incoming
and NOTHING ELSE. You are effectively running an infectious-prion
research lab. Treat it as such. ;-)

-- 
Andrew Gallagher

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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