Manybubbles created this task. Manybubbles added subscribers: Manybubbles, Aklapper, Haasepeter, Beebs.systap, csteipp. Manybubbles added projects: MediaWiki-Core-Team, wikidata-query-service.
TASK DESCRIPTION I don't think we will be able to complete a security review of BlazeGraph before we settle on it but we should think about it. The relevant points are these: 1. We'd like to expose SPRAQL to users. Its very powerful. It might be *too* powerful because it supports: 2. Federated queries. I imagine we'd have to turn that off or else it'd allow user to make sparql like http requests. Maybe one day we actually have some federation to do and its controlled with a whitelist or something. 3. ORDER BY. We _need_ order by but sometimes its implemented by materializing all the results in memory and then sorting them. We would have to prevent pure order by queries or use SPARQL AST rewriting (a Java plugin) to rewrite ORDER BY queries into a safer form. In SQL this changes: ``` SELECT * FROM foo NATURAL JOIN bar NATURAL JOIN baz ORDER BY bar.name, baz.name ``` into ``` SELECT * FROM (SELECT * FROM foo NATURAL JOIN bar NATURAL JOIN baz LIMIT 10000) ORDER BY bar.name, baz.name ``` 4. In general queries are killable and timeoutable (yay) but if they are able to consume the entire JVM heap then this is no longer the case. BlazeGraph handles this with "analytic" queries which aren't run on the heap but on a native heap. This make controlling their memory usage simpler. We really need to play with this. Both from a performance and stability perspective. It deserves both intentional trying to break it and randomized attack like you could generate with randomized testing ala lucene. TASK DETAIL https://phabricator.wikimedia.org/T90115 REPLY HANDLER ACTIONS Reply to comment or attach files, or !close, !claim, !unsubscribe or !assign <username>. EMAIL PREFERENCES https://phabricator.wikimedia.org/settings/panel/emailpreferences/ To: Manybubbles Cc: csteipp, Beebs.systap, Haasepeter, Aklapper, Manybubbles, jkroll, Smalyshev, Wikidata-bugs, Jdouglas, aude, GWicke, daniel, JanZerebecki _______________________________________________ Wikidata-bugs mailing list Wikidata-bugs@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs
