On Thu, Jan 7, 2010 at 12:13 PM, Dumitru Daniliuc <[email protected]> wrote:
> in addition to these standard functions, we'd like to whitelist some >> functions from a few extensions chromium uses: >> full text search (fts2.c): whitelist snippet(), offsets(), optimize(), but >> not fts2_tokenizer(). >> unicode data (icu.c): whitelist regexp(), lower(), upper(), like(), but >> not icu_load_collation(). >> >> >> Is there any reason these are still Chromium-only? Even though we're >> having problems getting different vendors to agree on SQL dialect issues >> with the spec, I think we should make an effort to keep WebKit unified. >> > > FTS and ICU are sqlite standard extensions that live in the sqlite tree. > Chromium compiles its own sqlite library and includes these 2 extensions; > I'm not sure if they're included in WebKitLibraries/libWebCoreSQLite3.a > though. > [resending from @chromium.org] Probably not. Last time I tested Safari for a sqlite-related security bug, I didn't see any fts or icu extensions. Chromium uses icu and fts2 (even though there is a newer fts3 module). These modules are useful to offline apps that want powerful text indexing and search. Isn't it every WebKit consumer's own job to deal with which version of sqlite to use? This is unfortunate because there are a lot of factors here. For example, we get grief on Linux for not linking to the system sqlite library. However one of the problems with doing that is that these sqlite extensions are compile-time options that are often simply not compiled in. etc. etc. Cheers Chris > > >> I'm also going to forward this message on to some of our security >> colleagues at Apple, and we might have more feedback shortly. >> > > great, thanks! > > dumi >
_______________________________________________ webkit-dev mailing list [email protected] http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
