Hello Faruq: On Mon, Jul 26, 2010 at 11:38 AM, M O Faruque Sarker <[email protected]> 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 _______________________________________________ tahoe-dev mailing list [email protected] http://tahoe-lafs.org/cgi-bin/mailman/listinfo/tahoe-dev
