[tahoe-dev] Multiple introducers announcing their presence on a grid

Zooko O'Whielacronx zooko at zooko.com
Tue Jul 27 06:24:53 UTC 2010


Hello Faruq:

On Mon, Jul 26, 2010 at 11:38 AM, M O Faruque Sarker
<writefaruq at gmail.com> wrote:
>
> I'm wondering if you could share your thoughts about the above somewhat
> plain idea of publishing the presence of new introducers same as new
> clients. By this any client can learn about new introducers and save their
> furls in the multi "introducers" config file and later to connect to them.
> But this plain implementation can bring serious security threats to the
> grid.

Let's see, so if I understand correctly the first part of #68 you have
already implemented—make the Client subscribe to more than one
introducer and use the introductions published by all of them. If I
understand correctly the patches to do that are attached to ticket #68
and may need more code-review, tests, docs, etc. in order to be
committed to trunk.

Hopefully we can get it all polished up by this coming Saturday and it
can go into Tahoe-LAFS v1.8β!

Then assuming that this first part is committed to trunk, do we want
clients to learn about the existence of introducers this way—the same
way that clients currently learn about the existence of storage
servers?

That's a good question. I don't think it is *too* bad of a security
threat. In the long run (#295) we should have a strong method of
controlling which servers will serve which clients which is
independent of the introducers, and even in the short run having
several introducers is probably not too much more of a security issue
than having one.

However, let's think of it like this: suppose we may or may not commit
the feature of clients automatically subscribing to new introducers
into Tahoe-LAFS v1.9. Then: is there anything that we need to have in
Tahoe-LAFS v1.8 or need to *not* have in Tahoe-LAFS v1.8 to make v1.8
clients and servers interoperate correctly with v1.9? As far as I can
think there isn't. The current protocol for IntroducerClient should
continue to be sufficient for v1.8 storage servers to announce
themselves to v1.9 introducers, for v1.9 storage servers to announce
themselves to v1.8 introducers, for v1.8 storage clients to subscribe
to v1.9 introducers and learn about both versions of storage servers,
and for v1.9 storage clients to subscribe to v1.8 introducers and
learn about both versions of storage servers. Can you think of any
reason that this would not work? (This is the "forward-compatibility"
question.)

Regards,

Zooko

http://tahoe-lafs.org/trac/tahoe-lafs/ticket/68# implement distributed
introduction, remove Introducer as a single point of failure
http://tahoe-lafs.org/trac/tahoe-lafs/ticket/295# distributed
authorization of access to nodes



More information about the tahoe-dev mailing list