Quicken to GnuCash (Windows) (Charles Day)

Charles Day cedayiv at gmail.com
Sat Dec 8 16:51:14 EST 2007


On Dec 3, 2007 7:44 PM, Andrew Sackville-West <ajswest at mindspring.com>
wrote:

> On Tue, Dec 04, 2007 at 02:12:03PM +1100, Charles Day wrote:
> > On Dec 4, 2007 10:33 AM, Andrew Sackville-West <ajswest at mindspring.com>
> > wrote:
> >
> > > I think that just highlights what I think the general problem
> > > is. Gnucash isn't written to secure the data that might be used by
> > > gnucash. It's written to handle that data. It's up to the user to
> > > secure that data. Personally, I much prefer securing my own data with
> > > methods I understand and to my own gut-check-level. Much better than
> > > (one of) the alternatives -- having the app secure it in some manner I
> > > don't understand and possibly can't recover it from.
> > >
> >
> > Andrew, why would the application's security methods be a mystery? It's
> open
> > source. Gnucash would not have to do the heavy lifting anyway; it would
> > probably just have hooks into a well understood and scrutinized open
> source
> > library. Using it could be optional. I can understand the argument not
> to
> > take this up based on priorities and limited resources, but not on
> > philosophical grounds.
>
> hmmm... I guess I don't disagree. My point, not well founded, is that
> security that I set up, I will understand (at least somewhat) and be
> able to recover data from. Security that some app sets up for me I
> will not necessarily understand. In the event I needed to recover data
> from that secured state would require that I jump through all the
> hoops required to 1) understand what was done and 2) get it to work in
> reverse. Both these are inherently a part of setting up your *own*
> security and don't require the extra legwork to make a recovery. I
> guess *I* prefer the legwork up front, in preparation for failure as
> opposed to doingthe legwork at the end, at the time of the recovery.
>
> Regardless of my twisted thinking though, I think you are right :)
>
> A
>
>
Great, so we'll see an encryption feature included in tonight's build?  ;)

But seriously, if the flat file format is kept, then something like GPGME
might be used. If GnuCash suddenly blew a fuse, recovery could be done on
the command line using GPG itself.

What is the future of GnuCash's back end? It may not be worth thinking about
protecting the current flat file via an API if it will soon be replaced by a
database.

Cheers,
Charles


More information about the gnucash-user mailing list