Easier custom reporting (maybe Lua)?

[Geert Janssens]

On Tuesday 25 October 2016 07:17:28 Sébastien de Menten wrote:
> On Sun, Oct 23, 2016 at 8:08 PM, Geert Janssens
> <geert.gnucash at kobaltwit.be>
> wrote:
> > On Sunday 23 October 2016 09:24:19 John Ralls wrote:
> > > > On Oct 23, 2016, at 8:53 AM, Sébastien de Menten
> > > > <sdementen at gmail.com> wrote:
> > > > 
> > > > Would it be feasible in gnucash to use the guile/scheme report
> > > > system to call an external process (a command line program) that
> > > > would return the proper html to display in the report ? The
> > > > external program could take arguments generated by the options
> > > > system of the report (the GUI that is used to customize a
> > > > report).
> > > > If so, we could have a more open system for report generation.
> > > > Piecash could be used by pythoneers but others could use a mix
> > > > of
> > > > sql + any external program to build reports.
> > > > 
> > > > Does this make sense ? Or are there blocking issues I am not
> > > > aware
> > > > of ?
> > > 
> > > Yes, it's possible: The quote retrieval code works by calling a
> > > perl
> > > program, gnc-fq-helper, from Scheme. We'd need someone fluent in
> > > Scheme to write the external interface code. Such a report
> > > wouldn't
> > > have access to the in-memory state of the database, though, so it
> > > would be current only with the SQL backend or a freshly-saved XML
> > > file.
> > 
> > Possible maybe. Desired I'm not sure.
> > 
> > There is an important difference between gnucash calling
> > gnc-fq-helper or adding an api to call whatever program on the
> > system. The difference being gnc-fq-helper is a script that comes
> > installed with gnucash and can't normally be altered by any user
> > except someone with administrator rights on the system. It's been
> > verified by the developers to not do any nasty things on your
> > system.
> > 
> > Adding an option to call whatever program on the system opens a
> > potential security hole. You are suddenly asking gnucash to run
> > totally unverified code. I'm not looking forward to this for
> > various reasons.
> The idea is more about a better integration between gnucash and 3rd
> party reporting extension. The unverified program gnucash woud call
> could anyway be called externally by the user, via the command line
> (i.e. it does not change a bit the security or I am missing
> something...). But thank to this better integration with gnucash, the
> user experience would be dramatically improved !
> Seen the complexity of today's legacy  reporting system in gnucash,
> that is not expected to be reworked in the coming months/years due to
> understandably higher priorities  (engine and backend), this
> integration via guile/scheme looks like a promising venue doable in a
> couple of hours/days.
> 
> Any scheme gnucash guru willing to scratch this itch ? My own scheme
> practice is under 15y of dust...

I understand the idea is better integration of gnucash with 3rd party 
reporting extensions. I don't think the solution is the right one here 
or at least not in the simplistic form as proposed.

But let me start with this: what you ask for is already possible now 
IMO. Gnucash has a feature to load custom scheme code at startup. This 
is used for example to add extra self-written reports. This same 
mechanism can probably be (ab-)used to let you call any external program 
you like.

With that in mind I will continue to argue against is promoting this to 
a standard feature of gnucash. I'm fine with people tinkering and 
extending gnucash locally. Those people however generally know more or 
less what they are doing. Ordinary users may not be aware of this.

I see this extensibility as a gap that should be closed by default and 
only open when someone explicitly wants to make use of it. So rather 
than adding an additional "call whatever you want" mechanism I'd add an 
option to *disable* loading custom scheme code by default and only allow 
someone with admin rights to enable it by setting a system level 
preference.

While this is not exactly what you asked for I'm afraid, it's something 
that has been on the back of my mind for quite some time. And since the 
topic got touched I want to clearly express my point of view on this 
matter.

As to your argument "the unverified program gnucash would call could 
anyway be called from the command line", this only considers the 
technical aspect of security. Allowing gnucash to run aribitrary code 
opens an extra vector of attack for social engineering. It could be used 
to entice people that would never use the command line to execute 
malicious code without them realizing it. The risk is small, but real 
and can be avoided by not allowing gnucash to run arbitrary code.


Regards,

Geert