Hi Ryan,
I think there may have been some misunderstanding here. The application is a
local application and thus needs no server, at least on the data side. But
multiple people may have access to the same machine. So while user control
is needed elsewhere, that certainly isn't on the local side. Just a simple
password would do.
The network/user control scenario is much more important in the
collaboration features of the software. I am still trying to work out
ultimately how best to do this (client/server, peer-to-peer possibly with
relay server etc). However the specific data that is being collaborated on
doesn't need to be stored remotely, unless of course I use a
check-in/check-out style system. Again, collaboration is way into the future
and so I'm not thinking along those lines just yet.
I have looked into the SEE extension again, just to make sure I am correct
in my assumptions, and it appears I am. I doubt I even get $2000 disposable
income in one year, let alone a month so that option would be impossible for
me at this time. Also it appears that you are responsible for compiling SEE,
again which I would find it very hard to do, never having compiled anything
in C.
On the other hand, searching is a necessity so it appears that encrypting
the data from the application itself is also not an option. So I think at
this point I am stuck
Cheers.
Damien.
-----Original Message-----
From: R Smith
Sent: Saturday, October 08, 2016 10:02 AM
To: sqlite-users@mailinglists.sqlite.org
Subject: Re: [sqlite] Protecting databases
Hi Damien,
We are obviously all fans of SQLite and keen to involve more people in
what is one of the best DB systems in existence and most widely used DB
in the World.
But...
SQLite answers a need that is quite specific (though widely used) in
that it is very small, very fast and, as a bonus, can be compiled right
into most software projects so distribution is not an issue - which
further means it is also server-less. This last feature makes it
specifically not well suited for large network-server and service type
applications and not well suited for user control. Encryption is easy
(as others explained) but your replies indicate you are more interested
in user control. While some extensions do exist to allow a form of user
control, I think what you really want is called PostGres or Maria-DB
(previously MySQL). They are equally free, open-source, they support
client-server architecture and both storage-encryption and user-control
are inherent to these systems, and they play very well with web-script
engines (such as PHP and its ilk).
Use SQLite for local storage that need not be protected from users with
access to the local file system. Store all your application settings in
SQLite, etc. It is not uncommon to use multiple database engines in a
single project. Right tool for the job and such.
Of the two alternate engines above, my preferred is PostGres, but there
are situations where Maria DB works a treat (such as the usual
LAMP-stack quick web-server solutions and the like) and it has some easy
and strong scripting capabilities.
Links:
https://mariadb.org/
https://www.postgresql.org/
Good luck,
Ryan
On 2016/10/08 9:18 AM, Damien Sykes-Lindley wrote:
Hi Darren,
You are correct in that genealogy is generally public. However more often
than not the information you want to publish may very well differ from
what is in your private database. You may have private notes telling you
what you need to do. You may have anecdotes shared by many family members
that may need to be kept private, at least until the involved parties are
deceased or otherwise choose to divulge it publicly themselves.
Even more importantly I may choose to add an address-book style feature in
there so you can easily group and contact appropriate family members for
whatever reason (special occasions etc). Of course that will be private.
Password protecting it is also good on many levels - if the database is to
be used online then it is needless to say that authentication would be
required for various people to view it. Even if I decide to make it local
only, there is the possibility that anyone sharing the computer or network
may peruse the database when you don't want them to.
Kind regards,
Damien.
-----Original Message----- From: Darren Duncan
Sent: Saturday, October 08, 2016 6:54 AM
To: SQLite mailing list
Subject: Re: [sqlite] Protecting databases
On 2016-10-07 10:46 PM, Damien Sykes-Lindley wrote:
Hi there,
My name is Damien Lindley, and I am, among other things, an independent,
hobbiest programmer. I have been blind since birth and thus all my
computer work relies on screenreader software and keyboard.
I have only just come through the brink of scripting into compiled
programming and so I guess I am still a beginner in many respects.
However I don’t work in C or C++, so most of my programming, if using a
library, relies on precompiled static or dynamic libraries. Or of course
libraries that are written or converted specifically for the language I
work in (FreeBASIC).
Recently, I decided I needed to create a piece of software that could
manage family trees, since there seems to be a lack of screenreader
accessible genealogy managers out there. I was advised the best way to do
this is to use a database engine. I was also informed that SQLite is
always a good choice for databases.
I must admit, I have never worked with databases before and so now I am
in the process of learning SQL. However looking at the programming API
for SQLite I cannot see any means of password protecting the database
without either buying a commercial extension to do this, or recompiling
SQLite with the authentication extension. Due to financial constraints
and unfamiliarity with compiling in C both of these are not an option for
me. Also I need a secure way to do this, as I think I read that the
SQLite version simply uses a table to store the user data, which of
course can be read and accessed elsewhere.
Are there any other options available for doing this?
Any help appreciated.
Thanks.
Damien.
Damien,
Why do you need to password protect the database?
Genealogy information is generally of the public record variety so there
is
nothing sensitive to protect. I am making genealogy software myself and
so am
familiar with many of the relevant issues.
I would say please explain why you think you need password protection for
this
project and then the real issue at hand can be addressed.
If yours is a network application and you don't want people on the open
internet
from accessing the database, fair enough, but that's an application-level
solution; what you're asking for here is that people who have direct
access to
the SQLite database file are blocked by a password, and this I question.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
