It's a possibility. It's already isolated as a playhouse extension (thanks to your previous request).
I leave the decision to you, but I'd like to point out that such warnings are common (and even expected) in crypto products. Even *tor* has something similar (maybe less bluntly phrased and without reference to British TV, but I guess it's a cultural thing :bowtie:), and [from experience] you get slapped with a wet fish by reviewers if you fail to do so.
The warning mainly refers to the possibility that my integration code has introduced something (I doubt it, but all developers doubt they have bugs, and yet - heartbleed happened), but Sqlcipher *itself* could be vulnerable as well (after all, we know even *OpenSSL* can be).
IMHO, both are good enough reasons for such a warning (and it can stay there as long as *tor* have theirs :grin:).

It's your decision whether to accept this to the playhouse or not, but here's my pitch:
We all know there's a huge need for crypto tools [nowadays](http://youbroketheinternet.org/). If you introduce [mildly] experimental crypto code into the playhouse - it will get reviewed faster and by more eyes than in a small and unknown project, and in a few years peewee can perhaps say "we have a fairly reviewed encrypted db engine".
If - instead - you decide to introduce crypto later on (and you'll probably choose pysqlcipher because it's widely accepted and runs on almost any hardware :wink:) - it would *also* need to carry such a warning, and the review process would only start *then* . So why not now?