Validate posts in dhtput

[miguelfreitas]

Use validatePostNumberForUser() when dhtput resource is known to be a post (like "postX", "replies", "mention" and "hashtag").

[genjix]

Is this what you were imagining? twister.cpp: http://pastebin.com/Dp6pzjf4

[miguelfreitas]

Very close! ;-)

Actually I didn't meant the dhtput RPC, but rather the node.cpp part, where it receives the request to store a certain value. This is where the real protection for DOS should go.

I'm happy you reach this issue because there is a very interesting decision here: the tradeoff between future expansion and DOS protection.

If we decide to validate all requests of known dht resources it will make sense as well to forbid unknown resources, right? otherwise they are given a kind of privilege. unknown single resources for known users are currently accepted, so i may easily create {"user", "pgp", "s"} in twister-html without requiring core update.

Should we forbid this to protect users from somebody storing arbitrary resources on the network? Then the future expansion might be harder. it is a though tradeoff. maybe some sort of prioritization is better suited so nodes may accept the unknown resources but they'd be always discarded first.

[thedod]

Like I said, you don't need to give up flexibility to maintain security.
You can allow plugins (e.g. a pgp "profile plugin) — i.e. a json meta-definition for a field collection (validity checks like max size or "this is a url and it shouldn't start with javascript:").
Once there's a machine-readable way to define a "profile plugin" (e.g. tox), "post plugin (e.g. linked post or a video conference)" and "url-preview plugins" (e.g. display images from whitelisted domains, twitter-card preview), all you need is for a developer to sign it (or simply do a twist with a "link-to-distro" payload) and you can have a secure upgrade system. The user can then decide which developers to trust (the default can be ["@twister"] for official plugins twister developers think are secure enough)).