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 > -------------- 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/tech/attachments/20061102/1e161a41/attachment.pgp>
