Cocoapods Podspec should include SQLITE_ENABLE_FTS3_TOKENIZER

SQLCipher
1

Currently, SQLCipher builds via the Cocoapods spec ‘SQLCipher/fts’ can’t use custom FTS tokenizers, as SQLITE_ENABLE_FTS3_TOKENIZER is not included in the build settings. Fixing this is trivial within the podspec, as seen in the proposed patch:

Without this change, the application must implement a post_install hook in its own Podfile to add the flag:

post_install do |installer|
  puts "Post-Install: Enabling SQLITE_ENABLE_FTS3_TOKENIZER for SQLCipher..."		
  sqlcipher_targets = installer.pods_project.targets.select { |target| target.name =~ /^SQLCipher$/ }
  sqlcipher_targets.each do |target|
        target.build_configurations.each do |config|
            old_defines = config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] || []
            config.build_settings['GCC_PREPROCESSOR_DEFINITIONS'] = old_defines + ['$(inherited) SQLITE_ENABLE_FTS3_TOKENIZER=1']
        end
    end
end
2

Hello @evands

Thank you for your interest in SQLCipher. As part of our distribution process, we maintain the same CFLAGS settings across all SQLCipher distributions, including Cocoapods.

With the 3.4.0 release, the cocoapods distribution has configuration parity with our existing distributions under the standard spec; we have kept the fts and unlock_notify only for backward compatibility as they no longer differ in their definition from standard. That is to say, the fts spec is only included now for backwards compatibility so that applications that previously relied on those specs don’t break. It will likely be removed entirely in the future.

We could consider adding SQLITE_ENABLE_FTS3_TOKENIZER to the standard set in the future, however we are going to defer this decision for the time being for a couple reasons. There is a documented security impact to enabling it, which may make it unsuitable for inclusion in the general distribution. In addition, this is not a commonly required feature (this is the first request we’ve had related to the compile time option in 8 years of general availability).

As you noted there is a simple workaround for individual applications using post_install, so you’re already on the right track with the preferred approach for the time being.

3

Thanks for your reply. I wasn’t aware of the security impact previously, but reading on it I now understand. Given that, I definitely agree with not enabling it by default.

If it were a common request, having a subspec which enables it would be nice, but since it isn’t, the post_install workaround makes sense. This ticket should serve as a useful resource to anyone else who might search zetetic.net about the issue.