2

What I want to do:

I am developing a CLI app which has a read-only database (sqlite using mattn/sqlite3) which should not be exposed and the binary is just an API over the read-only database.

I tried tools like packr but it gives File, string or []byte{} and the sqlx.Connect requires file path only

This statckoverflow question talks about using tempfile but that too stays on FS. I can't keep the DB file on FS as it can be accessed by anyone with access to the system.

What I have already tried

Keeping an encrypted file in storage and then decrypting it runtime and then storing it in sqlite in-memory db but when using multiple go-routines I'm facing a lot of issues like table not found which are already there on GH issues for mattn/sqlite3 repo and are unsolved. So, I can't work with in-memory database.

Jonathan Hall
  • 75,165
  • 16
  • 143
  • 189
ashishmohite
  • 1,120
  • 6
  • 14
  • 2
    Try the special file name ? https://www.sqlite.org/inmemorydb.html – KDEx Sep 29 '19 at 12:41
  • Already tried - doesn't go well with concurrent access from go routines – ashishmohite Sep 29 '19 at 14:18
  • If that "not going well with multiple go routines" would be a general issue, hardly anyone would use it, would they. Presumably, it does not do well with *your* code - hence you might want to show us what you did so far. – Markus W Mahlberg Sep 29 '19 at 14:21
  • 1
    In general: If you hand out the binary, [it is rather easy to extract payload](https://rednaga.io/2016/09/21/reversing_go_binaries_like_a_pro/). If the data can not be leaked: connect to a cloud instance (preferably via a REST API). – Markus W Mahlberg Sep 29 '19 at 14:26
  • I'm fairly confident that the sqlite API allows reading from memory. That just apparently isn't exposed in the Go driver layer. It may be possible to add that feature to the Go package. – Jonathan Hall Sep 30 '19 at 10:40

0 Answers0