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 > >
