report in python, a first version

John Ralls jralls at ceridwen.us
Tue Nov 15 18:28:38 EST 2016


> On Nov 15, 2016, at 12:58 PM, Sébastien de Menten <sdementen at gmail.com> wrote:
> 
> 
> On Tue, Nov 15, 2016 at 6:41 PM, John Ralls <jralls at ceridwen.us> wrote:
> 
> > On Nov 15, 2016, at 9:24 AM, Sébastien de Menten <sdementen at gmail.com> wrote:
> >
> > On Tue, Nov 15, 2016 at 4:17 PM, John Ralls <jralls at ceridwen.us> 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 Makefile.am 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 (report_test.py), I generate the Scheme code wrapping this python report (report_test.scm) with:
> > - the proper Scheme code for the options defined in report_test.py
> > - the proper Scheme code to call the python process (ie "python report_test.py")
> > 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 ?
> >
> 
> Sébastien,
> 
> 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.
> 
> 
> Any report written in guile can be malicious as it has (i guess) full access to the OS (syscall, file manipulation, etc) and to the gnucash engine (I guess the report could modify the book ... but I may be wrong). Any outside process can tinker with the gnucash books to corrupt them. So I do not see exactly what specific security threat would be avoided by blocking the specific case of a process running outside Gnucash pushing a string of HTML.
> 
>  
> 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?
> 
> Indeed, the json is just there to 1) initalise the 'options-generator' object (with the options information), 2) specify the process to call (via dynamic-wind) and 3) define the report (argument for 'gnc:define-report). It is just way more readable/editable than tinkering with scm code. But we could choose yaml (even more readable but must find a yaml parser for guile) or xml (less readable but xml reader available in standard guile library?).
>  
> Does PyCash ignore the lock table in the database, then?
> 
> 
> piecash is well aware of the lock table in the database but you can tell him to ignore it if you open the book in read only mode via
> book = piecash.open_book(book_url, readonly=True, open_if_lock=True)
> 
>  
> 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.
> 
> 
> Looks complex and probably a) requires compilation and b) does not allow to choose the python interpreter the user wants.
> (as a side note, it is as an important security threat as having a guile interpreter embedded or calling an external process ... the later being less dangerous as he can only be dangerous through the HTML string it returns)

Sébastien,

Heh, what about GnuCash *isn't* complex?

It's the html string that I'm particularly worried about, because that gets you to a well-known library with lots of well-known and well-documented vulnerabilities [1] and it's well-known that we we use an obsolete version. That's a very easy and tempting target.

I'm utterly agnostic about what format the report-config file is, but since Guile already knows how to read XML [2] and the fewer dependencies the better, I'd lean towards that.

Yes, having a Guile interpreter is also a security hole, though less well known and with a much smaller attack surface than WebKit. I'll be very happy indeed when it's no longer central to GnuCash.

Regards,
John Ralls

[1] http://www.cvedetails.com/vulnerability-list/vendor_id-49/product_id-10007/cvssscoremin-5/cvssscoremax-5.99/Apple-Webkit.html
[2] https://www.gnu.org/software/guile/manual/html_node/Reading-and-Writing-XML.html





More information about the gnucash-devel mailing list