I give up. I told 3 times what could be done, and after this you still do not know what you could do...
A last time I repeat it: - new option in node, paranoiaMode=true - if enabled disable the send of sensitive informations to fcp clients, trust no client - if enabled disable dda. I don't understand your argumentation that you want that clients support this mode. Of couse they support dda, but if the client runs on another box then the client must use non-dda. So a client supports both, and if the user enables the paranoia mode then dda is disabled. And maybe you understood me wrong, this mode is for the paranoic people AND for normal users that want to try new clients ... - if enabled only persistence=connection could be allowed, no global queue All this features are also nice if I want to give one or two friends access to my node, but I do not want that tey download files to the box that runs my node (dda), or that they insert my /etc/shadow file from the box where the node runs (dda), or they let persistent requests hanging around, or ... Ok now do what you want, I'm out of this... On 11/2/06, toad <toad at amphibian.dyndns.org> wrote: > No, I'm not sure exactly what needs to be done. > > On Wed, Nov 01, 2006 at 11:26:22PM +0100, bbackde at googlemail.com wrote: > > Not urgent, but nobody told me about this ticket so I assumed from > > toads words that he is not willing to address this issue at all. Sorry > > if I was wrong with that... > > > > On 11/1/06, Florent Daigni?re (NextGen$) <nextgens at freenetproject.org> > > wrote: > > >* bbackde at googlemail.com <bbackde at googlemail.com> [2006-11-01 > > >22:41:59]: > > > > > >> This sounds as if you are not willing to implement easy to use and > > >> easy to understand stuff into the node. > > >> You say that the client must handle it, you do not want to do anything > > >for > > >> it. > > >> What about clients that just do not provide a password prompt? What to > > >> do for the paranoid people? Nothing? > > >> > > >> Please, implement some of this things into the node rather than to > > >> shift all the work to the clients. They could fail, and this would > > >> compromise the anonymity of the (unsuspecting) user. If the node > > >> implements it there much lesser ways for the user to fail. > > >> > > >> And regarding dda: if the user tells the node to not to use dda then > > >> the node should do it. Even if you say it saves so much disk space. If > > >> the user is aware of this disable it. > > >> > > > > > >There are already tickets on mantis for that IIRC ... do it yourself if > > >you think it's urgent ;) > > > > > >> On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >> >On Wed, Nov 01, 2006 at 09:26:03PM +0100, bbackde at googlemail.com > > >> >wrote: > > >> >> On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >> >> >On Wed, Nov 01, 2006 at 09:04:43PM +0100, bbackde at googlemail.com > > >wrote: > > >> >> >> A user can run clients in a VM or on another box for exactly this > > >> >> >> reason (some users do this right now). This way bad clients cannot > > >> >> >> read more files than their own, and they cannot read node config > > >> >> >> files. The only way to do bad things is the FCP2 interface. And > > >their > > >> >> >> must be a way to prevent those kind of dangerous kind of access, at > > >> >> >> least via an option in the node (the most easy way to do it. Only > > >> >> >> requires to ensure an unfaked node). > > >> >> >> > > >> >> >> true? > > >> >> > > > >> >> >Maybe. What would you suggest? The easiest thing is a simple password > > >> >> >necessary for dangerous operations. But then, what operations are > > >> >> >dangerous? Some more than others! Is running unknown clients in a VM > > >> >> >common? > > >> >> > > >> >> Passwords are useless if a client is corrupted. If a client stores the > > >> >> password the corrupted client can use it. If a client asks for > > >> >> permission it would be ok, but annoys the user. > > >> >> > > >> >Untrusted clients wouldn't be given the password. What's the problem? > > >> > > > >> >> I would suggest to add a node parameter "paranoiaMode=true" that > > >> >disables: > > >> >> - direct disk access (only socket connections allowed) > > >> >> - the send of any worthful NodeInfo stuff like keys > > >> >> - and probably more > > >> > > > >> >What if you are e.g. running Fproxy over FCP? It seems to me that it > > >> >would be useful to be able to have some clients trusted and others not. > > >> >And I don't want yet another reason not to use direct disk access; > > >> >direct disk access saves _a lot_ of disk space. > > >> > > > >> >One interesting possibility would be to disallow dangerous operations on > > >> >non-localhost connections, but even then you have to worry about ssh > > >> >forwarding. > > >> >> > > >> >> Disallow anything that could access the box where the node runs. Only > > >> >> pure FCP2 is allowed. > > >> >> > > >> >> >> > > >> >> >> On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >> >> >> >Bad clients can read (and write!) all your files anyway. Secure > > >> >plugins > > >> >> >> >have been proposed but will be significant work. > > >> >> >> > > > >> >> >> >On Wed, Nov 01, 2006 at 08:32:36PM +0100, bbackde at > > >> >> >> >googlemail.com > > >> >wrote: > > >> >> >> >> Ok I understand. But its not easy for users to separate good > > >from > > >> >> >> >> faked freenet clients. > > >> >> >> >> > > >> >> >> >> Maybe all clients should sign their binary code in the jar file > > >to > > >> >> >> >> enure its unchanged. And maybe there is some way to provide a > > >> >> >> >> certificate to the node. Then the freenetproject people could > > >check > > >> >> >> >> the code of clients apps and give them a certificate that is > > >> >hardcoded > > >> >> >> >> in the freenet node. Only apps that have this certificate are > > >> >allowed > > >> >> >> >> to connect to the node if the user configured the "high security > > >> >> >> >> mode". > > >> >> >> >> Updating the node together with new clients is not too much work > > >> >and > > >> >> >> >> is acceptable for users. > > >> >> >> >> > > >> >> >> >> I don't know about the details of signed java code,... > > >> >> >> >> > > >> >> >> >> Maybe this would be a good item for the todo list (on > > >> >> >> >> bugs.freenetproject.org)? > > >> >> >> >> > > >> >> >> >> On 11/1/06, toad <toad at amphibian.dyndns.org> wrote: > > >> >> >> >> >You are wrong. Anyone with access to FCP can already: > > >> >> >> >> >- Upload arbitrary files which the node can access. > > >> >> >> >> >- Read your node reference, your peers and your config > > >> >> >> >> >- Add or remove peers > > >> >> >> >> >- Change config options > > >> >> >> >> >- Write to arbitrary non-existent files which the node can > > >access > > >> >> >> >> > > > >> >> >> >> >It has been suggested that a simple password or a full > > >> >> >> >> >username/password login might be useful. Nothing was ever > > >really > > >> >> >agreed > > >> >> >> >> >or implemented. > > >> >> >> >> > > > >> >> >> >> >So be careful who you let have FCP access! > > >> >> >> >> > > > >> >> >> >> >On Wed, Nov 01, 2006 at 07:36:48PM +0100, > > >bbackde at googlemail.com > > >> >> >wrote: > > >> >> >> >> >> Is it true what I see, is each FCP2 client now able to > > >retrieve > > >> >the > > >> >> >> >> >> private DSA key from the node, the key that uniquely > > >identifies > > >> >> >your > > >> >> >> >> >> node??? > > >> >> >> >> >> > > >> >> >> >> >> Do you think this is a nice feature? Someone could hack some > > >> >> >existing > > >> >> >> >> >> open source application, provide them to some incautious > > >users > > >> >and > > >> >> >> >> >> send their private DSA key to some big brother for > > >analysis??? > > >> >> >> >> >> > > >> >> >> >> >> I don't want to accept this without an important reason. I > > >have > > >> >no > > >> >> >> >> >> idea what a client could do with this private key, except to > > >> >send > > >> >> >it > > >> >> >> >> >> to some big brother. > > >> >> >> >> >> > > >> >> >> >> >> Or am I wrong? > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> >> >-----BEGIN PGP SIGNATURE----- > > >> >> >> >> >Version: GnuPG v1.4.5 (GNU/Linux) > > >> >> >> >> > > > >> >> >> >> > > >>iD8DBQFFSPACA9rUluQ9pFARAn/OAJ4uWpvQzVJ+AZY3dIANIkcAeHRsCgCfUiEP > > >> >> >> >> >TiZxr4+gbS4u+0iU7tM6JdM= > > >> >> >> >> >=ao4L > > >> >> >> >> >-----END PGP SIGNATURE----- > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> >> >_______________________________________________ > > >> >> >> >> >Tech mailing list > > >> >> >> >> >Tech at freenetproject.org > > >> >> >> >> >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> >> >> >> > > > >> >> >> >> > > > >> >> >> >> _______________________________________________ > > >> >> >> >> Tech mailing list > > >> >> >> >> Tech at freenetproject.org > > >> >> >> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> >> >> >> > > >> >> >> > > > >> >> >> > > > >> >> >> >-----BEGIN PGP SIGNATURE----- > > >> >> >> >Version: GnuPG v1.4.5 (GNU/Linux) > > >> >> >> > > > >> >> >> >iD8DBQFFSPpMA9rUluQ9pFARAttWAJ96NdhGKQgkMuZRcMsLU26W3vuaMwCfcjvT > > >> >> >> >vBdp6Ce0esREBFPdt5kKAWo= > > >> >> >> >=gIIZ > > >> >> >> >-----END PGP SIGNATURE----- > > >> >> >> > > > >> >> >> > > > >> >> >> >_______________________________________________ > > >> >> >> >Tech mailing list > > >> >> >> >Tech at freenetproject.org > > >> >> >> >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> >> >> > > > >> >> >> > > > >> >> >> _______________________________________________ > > >> >> >> Tech mailing list > > >> >> >> Tech at freenetproject.org > > >> >> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> >> >> > > >> >> > > > >> >> > > > >> >> >-----BEGIN PGP SIGNATURE----- > > >> >> >Version: GnuPG v1.4.5 (GNU/Linux) > > >> >> > > > >> >> >iD8DBQFFSP6EA9rUluQ9pFARAuKtAKCPUt/lvoXA5y/SSfWk3lJLYsA49QCdG7yK > > >> >> >yz+w9o6BOLfn/Em57p82VBc= > > >> >> >=MmKB > > >> >> >-----END PGP SIGNATURE----- > > >> >> > > > >> >> > > > >> >> >_______________________________________________ > > >> >> >Tech mailing list > > >> >> >Tech at freenetproject.org > > >> >> >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> >> > > > >> >> > > > >> >> _______________________________________________ > > >> >> Tech mailing list > > >> >> Tech at freenetproject.org > > >> >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> >> > > >> > > > >> > > > >> >-----BEGIN PGP SIGNATURE----- > > >> >Version: GnuPG v1.4.5 (GNU/Linux) > > >> > > > >> >iD8DBQFFSQsPA9rUluQ9pFARAp8yAJ43NIBj6VTS/q3GjPZcNMGAVJpERwCfdbSR > > >> >98BkPd1ubdg9xH56d1BhD10= > > >> >=Q46z > > >> >-----END PGP SIGNATURE----- > > >> > > > >> > > > >> >_______________________________________________ > > >> >Tech mailing list > > >> >Tech at freenetproject.org > > >> >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > >> > > > >> > > > >> _______________________________________________ > > >> Tech mailing list > > >> Tech at freenetproject.org > > >> http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > > > > >-----BEGIN PGP SIGNATURE----- > > >Version: GnuPG v1.4.5 (GNU/Linux) > > > > > >iD8DBQFFSRlMU/Z/dHFfxtcRArNeAKCEn8Huf/emEHuRnadzW2RpbUSqFQCdGZ9N > > >/0x3cB+DPP4luzR9n7+b+oQ= > > >=cp9v > > >-----END PGP SIGNATURE----- > > > > > > > > >_______________________________________________ > > >Tech mailing list > > >Tech at freenetproject.org > > >http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > > > > _______________________________________________ > > Tech mailing list > > Tech at freenetproject.org > > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > > > > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (GNU/Linux) > > iD8DBQFFSU6BA9rUluQ9pFARArGyAJ9/LFPsouRXGUqmvDJFay9tOMh2kwCeOua/ > E9Zz8pXks/NRopDz8Ps404I= > =rSrF > -----END PGP SIGNATURE----- > > > _______________________________________________ > Tech mailing list > Tech at freenetproject.org > http://emu.freenetproject.org/cgi-bin/mailman/listinfo/tech > >
