backend encryption / security
bhardwajs at gmail.com
Wed May 7 14:52:42 EDT 2014
Merging threads from Christian and Michael.
My summary from the thread is that:
Password protection feature seems to be something that would be useful to
have. Encryption is better left to specific tools. This would be easy to
explain to users. From Derek's email, it's a good idea to go ahead.
On Wed, May 7, 2014 at 11:22 AM, Christian Stimming
<christian at cstimming.de>wrote:
> Hi Michalis,
> thanks a lot for your offer for help, and thanks for explaining your idea.
> Contrary to what some other developers replied, the feature is indeed
> by at least part of the developers and surely by many users. I've discussed
> this previously, see (as you have probably seen already)
> and the thread following of
> From the user's point of view, having the possibility for an access
> password does make some sense and to my understanding this particular user-
> level feature would also be welcomed for inside gnucash.
> The picture may be different, though, when talking about an integrated
> encryption feature in gnucash. I, for one, would welcome that feature as
> so to provide some more access protection against "casual" access by
> unauthorized (e.g. shared user account as explained in the uservoice
> comments). It remains an open question on how to explain the limits of this
> feature clearly enough to the user. I.e., facts such as encrypting the data
> file doesn't make the log files disappear and so on. If you can explain how
> your solution solves the user feature request of casual access protection,
> without tricking users into a too self-confident feeling of security, I
> this is a worthwhile feature.
> Best Regards,
> Am Dienstag, 6. Mai 2014, 18:40:03 schrieb Michalis Kamprianis:
> > Hi,
> > I can see in uservoice, and I think frequently asked in lists, the
> > for encryption or password protection of the datafile.
> > Regarding database backends, I believe that database encryption should be
> > used if required, (although I understand that dbi may not be up to the
> > task).
> > Nevertheless, for xml backend, I think that I could try to implement an
> > based encryption (on saving) and decryption (on opening), based on code
> > from aescrypt. Aescrypt is available for unix, windows, mac, so the
> > implementation should probably be portable across platforms. The code is
> > some gpl and some freeware. Of course such a solution only protects data
> > rest (i.e. when data is read in memory it is not protected. Log files are
> > not protected. User configuration files are not protected - at least
> > initially, and so on) so it's not transforming gnucash to the most secure
> > accounting software out there, but solves the problem with datafile
> > misplacement or unwanted access.
> > The thing is, (a) I don't know if you're interested and / or agree in
> > implementing something like that, and (b) although I will probably manage
> > to code the open and save routines, I'm not sure I will not get stuck
> > somewhere, in which case it will either remain as an unfinished project,
> > I will need some help from somebody more experienced.
> > Your thoughts?
> > Regards
> > Michalis
> > _______________________________________________
> > gnucash-devel mailing list
> > gnucash-devel at gnucash.org
> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
More information about the gnucash-devel