➜

This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author Sebastian.Noack
Recipients Sebastian.Noack, berker.peksag, ghaering, serhiy.storchaka
Date 2020-01-21.23:30:02
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1579649402.81.0.570545701637.issue39408@roundup.psfhosted.org>
In-reply-to
Content 
Yes, I could use LD_LIBRARY_PATH (after copying /usr/lib/libsqlcipher.so.0 to /some/folder/libsqlite3.so), or alternatively LD_PRELOAD, and the sqlite3 stdlib module will just work as-is with SQLCipher. The latter is in fact what I'm doing at the moment, but this is quite a hack, and it's not portable to macOS or Windows.

Alternatively, I could fork the sqlite3 stdlib module, have it built against SQLCipher, and redistribute it. But I'd rather not go there.

That's why I'd love to see built-in support for SQLCipher in upstream Python, and as it is a drop-in replacement for SQLite3 which the stdlib already comes with bindings for, it seems to be a fairly small change on your end.
History
Date User Action Args
2020-01-21 23:30:02Sebastian.Noacksetrecipients: + Sebastian.Noack, ghaering, berker.peksag, serhiy.storchaka
2020-01-21 23:30:02Sebastian.Noacksetmessageid: <1579649402.81.0.570545701637.issue39408@roundup.psfhosted.org>
2020-01-21 23:30:02Sebastian.Noacklinkissue39408 messages
2020-01-21 23:30:02Sebastian.Noackcreate