backend encryption / security

Christian Stimming christian at
Wed May 7 14:22:52 EDT 2014

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 welcomed 
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 protection 
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 well, 
so to provide some more access protection against "casual" access by someone 
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, but 
without tricking users into a too self-confident feeling of security, I think 
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 request
> 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 AES
> 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 at
> 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, or
> I will need some help from somebody more experienced.
> Your thoughts?
> Regards
> Michalis
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at

More information about the gnucash-devel mailing list