report in python, a first version

John Ralls jralls at
Tue Nov 15 12:41:40 EST 2016

> On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdementen at> wrote:
> On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jralls at> wrote:
> Sébastien,
> That's a bit more "external" than I had in mind. The plug/connect any process part is a serious security issue.
> I don't understand the point of the json file. Users will want the report to display and then to be able to open the report options dialog to make changes like selecting a date range or modifying the accounts reported on, and expect the report to regenerate when they click "Apply". ISTM to accomplish that the report module needs to be in control and to pass to the Python report-builder the options parameters. The second thing that won't work is using PyCash: The user wants a report on what her book looks like in memory, not what it looked like the last time she saved, so the report will need to use the python bindings and connect to the current session.
> It looks to me from the that building guile-json requires Guile-2.0, which you won't have if you're using the Guile in the GnuCash Windows installation. You could try to simply copy the four .scm files into share/guile/1.8/ and see if it works. It will only if the author didn't use any Guile-2-only features.
> Regards,
> John Ralls
> On the security risk, it is no different than running the same process outside GnuCash (in a terminal for instance), or is it ?
> The json file is there to be able to specify the options for a report in a better way than writing Scheme in an scm file. Currently, for a given python report (, I generate the Scheme code wrapping this python report (report_test.scm) with:
> - the proper Scheme code for the options defined in
> - the proper Scheme code to call the python process (ie "python")
> Instead of having to generate scheme code, it would be better to have a json file per report (report_test.json) that could be used to instantiate the report in GnuCash.
> For piecash, there is no specific issue as the change in the book are immediately serialised to the SQL backend. However, for the xml backend (that piecash does not support anyway), the GnuCash file should be saved before. But nothing forbids someone to use the official python bindings to connect to the current session and do as you describe. However, how the python bindings know to which session to connect if there are multiple files opened at the same time ? and can they open a session in a separate process while GnuCash has a lock on the file ?


A process running outside GnuCash isn't pushing data into a running instance of GnuCash, so yes, it's significantly different. The ancient libwebkit we use has tons of known vulnerabilities that could be exploited by injecting malicious HTML or JavaScript.

Maybe I misunderstand how the json file would work. Would it just initialize the options which can then be edited in the report's options dialog, or are the options in the json file the ones that the report gets and the user must edit the json file in order to change them?

Does PyCash ignore the lock table in the database, then?

To connect to the current session I think one would need to use the Python connection in src/python or the Scheme interpreter. No external process is going to be able to get at the running GnuCash instance's memory.

John Ralls

More information about the gnucash-devel mailing list