On Sat, Apr 14, 2007 at 12:58:29PM +0200, Florent Daigni?re (NextGen$) wrote: > * bbackde at googlemail.com <bbackde at googlemail.com> [2007-04-14 11:27:50]: > > > One more question: DDA makes most sense when I want to PUT (write) > > files from a read-only medium like a CD. But with the current TestDDA > > implementation I would not any longer be able to PUT files from a CD > > using DDA (because the client cannot write the file to the requested > > directory), true? I have to transfer all big files using DIRECT to the > > node... > > Well, yes the node will refuse to read things if it can't write into > that directory; TestDDA architecture doesn't allow us to do otherwise. > The current behaviour sucks as well: imagine that the node and the > client aren't on the same computer ; the client asks /etc/passwd to be > inserted into freenet using DDA ... The node will accept it as it also > exists on his side but the content of the files is different. > > In the long term we will ask the client to send us a salted hash of the > full content in ClientPuts so that we can ensure it has read access to > the file. Toad wants that the node chooses the salt and that it is not > predictable ... it involves using a challenge/response mechanism > => more complexity won't be implemented "soon"
That's one option. Another option would be to send the file over the connection as in UploadFrom=direct, but also include the filename. The node would compare the file sent over the connection with the file on disk and if they match, use the file on disk. If they don't it would treat it as a direct upload. Would this be simpler for a client to implement? Bback/other client authors: Do you need chunking support? I had hoped to avoid it as most of the time the node and the client are on the same server, but if it is the price we pay for you to use a single connection, then we will pay it. > > I am convinced we need the hash to be salted but I'm not convinced that > we have to randomize it on a per-request basis : We could send an > identifier in the NodeHello message and ensure it matches the salt. > @toad any problem with that approach ? > > If there isn't any I might implement it soon. > > > In this case the current TestDDA should never become mandatory. > > The tradeoff is speed vs security in multi-user environments. When I say > "will become mandatory" you shall understand "will be the default > configuration of the node" ; In spite there is no plan to get rid of the > configuration setting yet, FCP client authors should assume that the > node won't let them proceed unless they do a TestDDA. > > Well, I'll make it clear on the wiki. What I suggest is that you don't > send testDDA messages preemptively : ClientPut/Get requests with testdda > enabled are cheap to handle ... If the node is old it will work, if not > it will reply with a ProtocolError and then you have to do the TestDDA > proceedure... If it completes successfully you re-send the ClientPut/Get > with dda otherwise you use direct mode. > > NextGen$ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: <https://emu.freenetproject.org/pipermail/devl/attachments/20070414/c5cd9e64/attachment.pgp>
