Custom reports do not load after upgrade to 2.6.4 on OSX

[John Ralls]

> On Oct 21, 2014, at 7:19 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Tuesday 21 October 2014 07:01:05 John Ralls wrote:
> > > On Oct 21, 2014, at 3:44 AM, Geert Janssens
> > > <geert.gnucash at kobaltwit.be <mailto:geert.gnucash at kobaltwit.be>> wrote:> 
> > > On Monday 20 October 2014 12:23:12 Derek Atkins wrote:
> > > > John Ralls <jralls at ceridwen.us <mailto:jralls at ceridwen.us> <mailto:jralls at ceridwen.us <mailto:jralls at ceridwen.us>>>
> > > > writes:
> > > > 
> > > > [snip]
> > > > 
> > > > > It seems that the processing of config.user isn’t setting the
> > > > > default
> > > > > path, so load is looking in the current pwd. Try changing your
> > > > > config.user to say
> > > > > (load gnc-build-dotgnucash-path(“saltant-invoice.scm”)) etc..
> > > > 
> > > > Just to be clear, this should probably look like:
> > > >   (load (gnc-build-dotgnucash-path "saltant-invoice.scm"))
> > > 
> > > While that is a good workaround it tapers over the actual bug.
> > > 
> > > The format used by John W. used to work until gnucash 2.6.3 and
> > > stopped working on 2.6.4. I can even reproduce this on Fedora so
> > > it's not OS X specific.
> > > 
> > > I have traced it back to my patch for
> > > Bug 711567 - Cannot save a custom report if a path contain diacritic
> > > chars
> > > 
> > > And looking back it's relatively easy to explain: until 2.6.3 it was
> > > guile that loaded the config file and ran the commands in it. In
> > > this case it is a bunch of load commands with relative path names.
> > > Guile will resolve these path names relative to the config file.
> > > 
> > > In gnucash 2.6.4 though the file is loaded by the c code and the
> > > commands in it are passed as a plain string to guile. In this case
> > > guile no longer knows about the location of the original config
> > > file and can no longer resolve the relative path names correctly.
> > > 
> > > I have some mixed feelings on how to deal with this.
> > > 
> > > The proper solution is to make guile handle pathnames with
> > > diacritical characters correctly on Windows. I've spent about a
> > > week trying to do so with the help of both the mingw and the guile
> > > community and failed. I don't feel like spending even more time
> > > trying to work around broken charset support in an external library
> > > on Windows.
> > > 
> > > On the other hand Derek's workaround is fairly easy. So I'm tempted
> > > to just update the wiki page that explains how to load a custom
> > > report and continue with more pressing matters.
> > > 
> > > What do you think ?
> > 
> > One possible solution is to get Guile out of the file-opening loop.
> > Having a configuration file that’s directly executed by Guile is a
> > rather glaring security hole; it would be much better to make it an
> > ini-style file and do everything in C/C++ up to passing the contents
> > of the files to a Guile function that registers them as add-on
> > reports. That’s not really a suitable change for the maint branch,
> > but we should consider it for 2.8.
> > 
> I understand your reasoning. However a custom report in itself is essentially unrestricted scheme code as well. So how is loading such a file via C/C++ any less of a glaring security hole than having it done in guile ?

It’s not if the C/C++ code just passes arbitrary code to Guile for immediate execution.
I’m proposing that the custom report should be passed to the report-registration code instead so that the report must be selected from the menu to execute. It would be even better if reports could be sandboxed, but that’s probably too hard.

Regards,
John Ralls